SMF Support > SMF 2.0.x Support

Settings.php re-set to default values???

(1/2) > >>

dom-sm-pig:
Hi

I'm fairly new to SMF, but I set up my club's SMF forum on a Hostpapa shared server a couple of months ago with no real problems until yesterday. (mtbpigs<dot>org<dot>uk<slash>forum)

However, I checked my email this morning to see a bunch of the dreaded 'SMF database error!' emails in my inbox. Checked the site and just got the 'cannot connect to database' error page. Left it for a bit, but no improvement.

So I had a look around and found that the file 'Settings.php' had been changed last night at 7.03pm, and that all the variable values in it were now back to the out-of-box defaults - like a factory reset if you like. So of course it couldn't connect to the DB...

'Settings_bak.php' had been 'reset' too, so I couldn't use that to restore the settings I needed. Luckily I was able to work out what they needed to be, and soon got it working OK with a manual edit of the file.

Question is what on earth happened?? I never touched anything. We have 2 other admins, and they both swear they never touched anything either (I trust them). The file security on Settings.php was (and still is) set to 644, which I believe is the recommended security level and is (I think) pretty secure? How can I stop this happening again??? Are other forum files at risk?

Obviously I've backed up 'settings.php' locally now, but even so I don't really want to keep doing this. Was I hacked?  :o

Thanks in anticipation of your support
Dom

MrPhil:
Most likely your host restored a backup of Settings.php. The database errors probably emptied out your Settings.php (due to a nasty bug in SMF) and someone restored a backup. Unfortunately for you, it wasn't the current configuration.

BTW, it's easiest to "fix" Settings.php by downloading repair_settings.php (http://wiki.simplemachines.org/smf/Repair_settings.php) and running it.

When done, and you're happy with Settings.php, make the file Read-Only (444 permissions). This will prevent it from being overwritten by the SMF bug when you get a quick succession of database errors.

dom-sm-pig:
Thanks MrPhil for this excellent support response. I wish the services that I pay for had support this good...

I'll follow all your advice. Just for avoidance of doubt - are there no down-sides to setting the security so high on Settings.php?

K@:
Nothing that SMF, itself, does SHOULD change that file.

If some mod install wants to write to that file, it should complain about it, when you install the mod. So, if you need to, you can change the permissions, then, and change them back, afterwards.

I don't recall seeing any mods that DO edit that file, though.

MrPhil:
Settings.php is completely rewritten every time there's a database error. This is a stupid design flaw that could have been handled so much better (see my sig > SMF fixes). Under certain conditions of closely-spaced database errors, it can end up emptying out Settings.php, leaving it 0 size.

As the Settings.php rewrite is simply to record the timestamp of the last database error (is that even used anywhere?), it does no harm to make the file Read-Only. If you're doing something to modify Settings.php (such as running repair_settings.php), you will need to temporarily chmod it to make it writable.

Navigation

[0] Message Index

[#] Next page