SOLVED ADMIN problem: Failed to initialize storage module

[jhaeusler@mac.com]

I did it. Hope my description helps others. It took me 2 days to figure it out.

Problem: I couldn't log in to the Admin area, the error was always "Failed to initialize storage module".

It was clear that the problem was that the session.start() in the index.php in the adminstration directory didn't work.

Before you try anything else (like I did), check your setup, because it seems that it's a PHP problem. It is most definitely not a MOS bug, although there must be ways to avoid the trouble, but I am not a coder.

My setup:
Apache/2.0.49 (Linux/SuSE)
PHP 4.3.4

Now as long as everything else seems to work (your "frontend" MOS shows up and you can log in as admin and make text changes from there, which means that your DB is set up correctly) and as long as you are sure that the /tmp or whatever dir that you're trying to write the session data to is really writeable (check your php info for the session.save_path and check via shell that the dir that is named there is writeable):

Make sure that the session.save_handler is set to FILES, *not* USER.

This solved my login problem.

Additionally, if your provider gives you confixx (like 1&1, my root server provider does), you need to change those things in confixx' own "httpd special" area. enter "php_value session.save_handler files" without the quotes there, wait some minutes, check if the change is visible in your php info and then:

Restart Apache.

For my server, it's

/etc/init.d/apache 2 restart

but that will differ on your server so please do some google research if you're a newbie, it's not too hard.

Again: Though I tried all the other things mentioned here, I had set them all back to the initial settings. The session.save_handler setting is the only thing I needed to change for the admin login to finally work.

So there's a good chance that yours will, too. Even with safe_mode on.

And to make this post even longer: I found this info in several PHP forums, it's a well known PHP problem in some versions. An upgrade to PHP 4.3.7 might have helped as well, but I didn't want to go into that.

Hope it helps some people, now let's get working. :)

[tanmar]

Hi!
Ich this works you are my personal hero! I'm struggeling with the same problem and found the bug report on php.net. I tried the update to php 4.3.8 but the problem still persists. I could have known that before, if i would have read the bug report completely :-(

The problem evidently arises if scripts, which are using the built-in functions for session handling and scripts which are using custom session handlers are running alternately.

Your solution sounds reasonably - I will try that. I have just one question: Are you sure with "php_value session.save_handler files"?

To turn safe mode off I use "php_admin_value safe_mode off"? Shouldn't it be "php_admin_value session.save_handler files" accordingly?
Thx for your help!
Marco

[jhaeusler@mac.com]

hi,

I really am not sure about the difference between "php_value" and "php_admin_value", maybe a php expert can jump in here?

all I can tell is that it did work on my set-up. hope it does with yours, too.

I personally and unfortunately stopped using mambo, but feel free to mail me with further questions, if I can help.

[tanmar]

Ok - I tried your solution. First everything went well and I was already happy. Unfortunately a few days later i suddenly had to see this ugly message again. The problem seems to occur less often but it still persists. Thx anyway!

[richard.h]

Originally Posted by jhaeusler@mac.com

hi,

I really am not sure about the difference between "php_value" and "php_admin_value", maybe a php expert can jump in here?

all I can tell is that it did work on my set-up. hope it does with yours, too.

I personally and unfortunately stopped using mambo, but feel free to mail me with further questions, if I can help.

That's an easy one: if you set some value in the httpd.conf via php_admin_value it can not be overwritten later in php code with the likes of ini_set etc ...

Which is quite useful if you have a shared envireonment and set a custom open_basedir or include_path for example.

[redbob]

I'd just like to confirm that this fix worked for me.
I'm running php 4.3.9/apache/windows and kept getting "Failed to initialize storage module"

i changed session.save_handler from 'user' to 'files' and everything works great now.

thanks to the OP for the fix

[mambo_chris_au]

According to PHP session.save_handler is set to files as the default.

[redbob]

Originally Posted by mambo_chris_au

According to PHP session.save_handler is set to files as the default.

it wasn't on my system. i did a clean install of Wamp5 with the php4 patch.

[receptor]

according to my phpinfo, both local and master values of session.save_handler are set to files, and i still cant login cuz of this disturbing message. my provider is not likely to upgrade his php (currently 4.3.10). any ideas?

[chette]

My provider has 4.3.10 installed, and I also get this problem. I did, however, see this error in the list of bugs in PHP.net.

I've done a lot of searching, got a lof of suggestions, and forwarded them to my provider. We've been trying them all one by one. Nothing seem to work so far.

BTW, this bug also occurs in our installation of TikiWiki.

[mambo_chris_au]

Originally Posted by chette

My provider has 4.3.10 installed, and I also get this problem. I did, however, see this error in the list of bugs in PHP.net.

I've done a lot of searching, got a lof of suggestions, and forwarded them to my provider. We've been trying them all one by one. Nothing seem to work so far.

BTW, this bug also occurs in our installation of TikiWiki.

refer them to:
http://forum.mamboserver.com/showthread.php?postid=127609&highlight=4.3.10#post 127609

[Gorlok]

This help me a lot! Thanks!

[futurahost]

Hello

Strong workaround is:

Edit your php.ini this way:
auto_prepend_file = /usr/local/lib/php.ini.prepend

On your /usr/local/lib/php.ini.prepend file put this:
<? session_module_name("files"); ?>

Of course, you can place your prepended file wherever you like, as long as you state it correctly on your auto_prepend_file directive of php.ini.

We haven't seen this issue anymore on any of our servers after applying this "patch".

Regards

Agustín Povarchik
FuturaHost.Com