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.

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?

share|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

2 Answers 2

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'

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

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.

share|improve this answer

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.