The disk on a Ubuntu server filled up causing a website to fail and some database corruption. After freeing some space (rogue wordpress backup plugin) and reimporting the database we found some functions of the site where not working.

I fixed some of the problems by changing the PHP upload_tmp_dir do be something other than /tmp. I still had issues but then I changed the mysql tmpdir to be something other than /tmp

/tmp was owned by root, had 777 permissions and I was able to write to it at the command line. I've not yet removed and recreated the directory as I want to understand the problem.

What could be causing the problems with applications writing to /tmp? How can I diagnose and get to the root of this issue?

link|improve this question
Might be worth setting the shell for the www-data user to /bin/bash (with chsh), changing to the www-data user (with su www-data) and then seeing if you can write to the /tmp directory from there. That should make it a bit easier to debug. Importantly, though, don't forget to change the shell for www-data back to /bin/false afterwards. – Andy Smith Jun 30 '11 at 10:46
that was a good idea although did not show anything. I was able to write to /tmp while I was the www-data user. i also tried mysql user. – ollybee Jun 30 '11 at 12:02
What error messages are you getting then? Sounds a bit odd if the www-data user can write to it. – Andy Smith Jun 30 '11 at 13:45
Nothing in error logs, just certain features not working in the site, which worked again after the change. I'm going to write some simple scripts to reproduce the issue as I appreciate Ive been a bit vague. – ollybee Jun 30 '11 at 14:07
Yeah - to be honest, it doesn't seem as though writing to /tmp is your problem, at least as far as PHP is concerned. Maybe MySQL or Apache are trying to use /tmp for something, and need restarting? – Andy Smith Jun 30 '11 at 14:27
feedback

2 Answers

Is /tmp partitioned seperately on your system? If so perhaps it remounted as read-only during your recent problems.

Ensure that the permissions are completely correct, you should have the sticky bit set on temp.
'chmod 1777 /tmp'

link|improve this answer
it's not separate, I can write to it. stickybit is set. – ollybee Jun 30 '11 at 12:03
feedback

Is the system running AppArmor or SELinux? If so, these may be denying access to specific applications (but shells are unrestricted). Check /var/log/apparmor/ or /var/log/audit/ for permission denied messages.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown

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