No access to administration on new Mambo installation

[#1]

Hi
I have installed the latest version of Mambo CMS, but cannot log in to administration to make any up-dates.
I have the following warning (along with others that seem to spring from this one!) which seems to be a the centre of the problem:
Warning: Unknown: open(/tmp/sess_833d38c98fa89393816665b2165cac00, O_RDWR) failed: File too large (27) in Unknown on line 0
Has anyone got any suggestions about fixing this?
Thanks

[#2]

Hi Jon
The /tmp is all choked at the moment. A short history of recent session problems can be found <a href="http://community.plus.net/forum/index.php/topic,84853.msg701395.html#msg701395">here</a>. You'll need to set your own session.save_path. Unless you fancy editing all the scripts using sessions, the easiest way to set this is with a custom php.ini file, as linked from the link here or from the new ccgi faq. Then use either the symlink method or the wrapper method, or just shove a copy of the php.ini in each folder containing scripts.
Gabe

[#3]

Thanks for that answer; I am relieved to disover it's probably not my fault...

[#4]

Hi Gabe,
I have seen your numerous posts on this subject (and related) and I am hoping that you may be able to point me in the right direction - and hopefully get a few things straight in my head.To say I am getting bogged down and confused with this issue would be an understatement! 
First thing I must say is my php scripting knowledge is probably in the 10-15% range, so I am by no means knowledgable in this field!!
Secondly, I apologise for what is a long winded posting...
That said, here are my dilemas....
I am in the middle of developing a new site using Joomla with the Virtuemart ecommerce module wrapped inside it. I was also using PMOS helpdesk wrapped inside the site and all was going well.
Then the CGI server meltdown/shutdown/upgrade weekend came along and despite my worst fears, everything came back online the following week without issues.
However, I have now run into a problem with the PMOS helpdesk scripts that is obviously being caused by the /tmp issues not handling the sessions correctly.
(I have no problems with the Joomla or Virtumart scripts presumably (?) because the site does not offer logins or actual purchasing - it is just being used as an online catalogue)
After discovering the various threads about this problem, I managed to get the PMOS (frontend) script working again by creating my own SESSIONS directory and modifying the "include" script, but have then subsequently discovered that none of the backend admin functions are working.
It would appear now that I am unable to login successfully and I am getting different errors that (according to what I have managed to dig out via Google) are caused by various reasons beyond my current level of understanding - namely:
Warning: Cannot modify header information - headers already sent by (output started at /share/storage/01/fl/domain/pmos/include.php:1) in /share/storage/01/fl/domain/pmos/stats.php on line 29 .... (this is appearing on virtually all the backend scripts)

After much hair pulling and colourful language, I decided to scrap PMOS and tried to install HESK helpdesk instead.
Well, that also failed because of the install script being unable to open a session - same problem I am guessing. However,they provide a script for session testing and that basically gives the result that my host is not handling sessions correctly.
So, my question is......
From your postings I see that you have said that the /tmp is all choked at the moment, and I am wondering whether you (or anyone else) knows if this is something that PN will be sorting out in the next few days, or are we all to be left to our own devices in trying to get these problems sorted ourselves?
To be honest, I have tried to get to grips with your detailed info about using custom php.ini files etc, but this is something that quite frankly is beyond my level of experience, so without PN fixing whatever has changed over the last 72 hours (ish), it will leave people like me pretty much stuffed
Finally, sorry for dropping this question in your lap, but I posted a ticket into PN about the inital problem and after 30+ hours had received no response. I only managed to sort my initial problem with help from Tonyr in another thread.
Thanks in advance for any light you might be able to shed on this for me

[#5]

Hi SkySurfer
My posts are a bit numerous. I think I probably talk too much.
Yes, I'd expect Plusnet to fix the current problem when the necessary people get back to work. I hope they will also make changes to reduce the risk of similar problems in the future.
I'm not quite clear about the headers-sent message. It may be that the modification is being included at too late a position. It wouldn't be a trivial job to find all of Joomla's files with a session_start and edit just those. I don't use Joomla, but I have a test install currently working with the wrapper method, though I quite understand you might not want to use that.
If you'd prefer to wait for Plusnet, you can probably just point the save_path used in your include back to /tmp. (If you still have problems after Plusnet fix theirs, then you might need to remove some of your edits.)
Gabe