Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm running 2 magento apps on my web server and I accidently set "chown -R www-data:www-data *" from the root of the server. Meaning, all the files were owned by the user root.

This immediately spawned problems on the magento websites, namely: mysql didn't connect because it was supposed to use the "mysql" user.

I since fixed that, and set the web page files to be owned by www-data.

The websites run fine now, but when I try to finalize an order, it hangs there for a minute before timing out. The order registers on the backoffice but it doesn't display the "Order sucessuful page" as it is supposed to.

I'm running nginx & php-fpm, and the php-fpm log reads:

[22-Mar-2013 13:31:24] WARNING: [pool www] child 1791, script '/var/www/website.com/index.php' (request: "POST /index.php") execution timed out (1436.378897 sec), terminating
[22-Mar-2013 13:31:24] WARNING: [pool www] child 1791 exited on signal 15 (SIGTERM) after 1600.011818 seconds from start
[22-Mar-2013 13:31:24] NOTICE: [pool www] child 2717 started

What's happening? Can this be occuring because some files aren't owned by their proper owner? If so, which files/folders are those and what owner is it supposed to have?

Edit: It must be something to do with postfix. A normal php script echoing "Hello World" renders just fine, when I put a mail() function in there it hangs.

share|improve this question
4  
This is one of those times that you have to first slap yourself, then take a deep breath, and finally restore from backups. You'll spend a lot more time trying to manually fix this. –  jamieb Mar 22 '13 at 14:59

2 Answers 2

up vote 1 down vote accepted

Assuming you were root when you did this and that it completed the chown (and wasn't cancelled with CTRL-C quickly).

When I hear something like this -- that a chown or chmod (or an rm -rf) was done recursively to the entire filesystem, I tend to suggest it's time to start over. You're going to be chasing down issues for, well, ever. This is an extremely destructive thing to do to a Linux box, and many of the subsequent problems will be less than obvious as to what's wrong (especially if some other guy unaware of the chown -R comes along and is trying to troubleshoot things).

Depending on your Linux distribution, some maintain information about the original ownership and file permissions in their packaging system. It may be possible to 'reset' the permissions to how they were when the package manager installed them. This link, for instance, speaks to how to do it on RPM-based distros: http://www.cyberciti.biz/tips/reset-rhel-centos-fedora-package-file-permission.html

At the end of the day, though, I'd really sorta recommend starting over if that's at all an option. 'chown -R' on * is one step up from 'rm -rf *', but the end result may end up being the same -- easier to start over.

share|improve this answer
    
I'm running debian squeeze. I appreciate the feedback, but I'm fairly certain that if I fix postfix I'll be good for the weekend at least. Next week I'll probably consider starting over, until then I'd like a fix asap. –  Pedro Peixoto Mar 22 '13 at 15:02
    
I cannot vouch for this link, as I've never used it myself, but.. sysadminnotebook.blogspot.com/2012/06/… –  Nex7 Mar 22 '13 at 15:09

If you ran that command on /, all the files are owned by your webserver (www-data) user not root. Without further context into your system I imagine a connecting system to your application can not write to its file. Is postfix started?

You probably wont like this answer but the best solution is to remake the system, reinstall the apps and just point it to the same database.

There are a lot of important permissions throughout a Linux system and just fixing the bare minimum to get your application working may leave serious security issues. For example right now your webserver can write to your /etc/shadow file.

share|improve this answer
    
I'd have to agree here, the only real way back is to restore your latest backup. There is no undo for a command like this. –  Snellgrove Mar 22 '13 at 15:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.