Please Note: The problem I describe below seems to have "gone away" on its own. But that's not very comforting, so I'm hoping for a solution, or at least an explanation, should it recur.
I was just preparing a Slicehost virtual server for a LAMP role, using the Ubuntu Lucid server (CLI-only). I created an account for myself (yukondude) but was doing most of the installations as root. At some point in the process, the mysql-server package (aptitude install -Pr mysql-server) failed with this error:
Unable to set password for the MySQL "root" user
An error occurred while setting the password for the MySQL administrative user.
This may have happened because the account already has a password, or because of
a communication problem with the MySQL server.
This was the first time mysql-server had been installed, so the problem couldn't have been a previous password. The installation script then dumped these lines to the terminal:
100903 19:57:05 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Can't create/write to file '/tmp/iblv4tJ0' (Errcode: 13)
100903 19:57:05 InnoDB: Error: unable to create temporary file; errno: 13
100903 19:57:05 [ERROR] Plugin 'InnoDB' init function returned error.
100903 19:57:05 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
ERROR: 1146 Table 'mysql.user' doesn't exist
100903 19:57:05 [ERROR] Aborting
It hung at this point, so I manually killed the installation processes.
I then discovered that the Apache2 server was refusing to serve my test index.html file, instead producing a 403 Forbidden message, even though the permissions for /var/www/index.html were wide open and the Apache config hadn't changed. I was also unable to log in through SSH to my yukondude account, and the command su - yukondude produced a cd /home/yukondude Permission Denied error (I'm afraid I don't have a copy of the exact error message). The permissions and ownership for /home/ and /home/yukondude/ were perfectly normal. Looking back at the mysql-server errors, I wondered if the access to the file in /tmp/ was related.
What could've caused this bizarre permissions problem? I've never seen anything like it before. I wondered whether PAM might be involved, but I don't know that system as well as I should. I'm not sure whether the mysql-server install was really the culprit, or just a victim of the permissions problem that cropped up at that moment.
I tried a complete re-install from a fresh image with the exact same result. My third and final attempt did work (the difference was that I updated my package versions before any installations), so I appear to be in the clear this morning. But I'm nervous that the same problem might someday re-occur. I tried Googling for help, but haven't figured out a good search phrase. Any suggestions?
Update: I'm going to start a bounty. As I pointed out, this problem isn't affecting me anymore, but I sure would like to have an inkling of what happened. I'd also appreciate comments from anyone who's experienced something similar in case those circumstances provide clues.
Try
chmod +t /tmpand see if that fixes it.One pretty common thing that could have happened is that you ran chmod or chown with the wrong parameters.
A quick search of serverfault for recover chmod returns lots of questions describing similar symptoms where the person ran the wrong chmod command.
Could be your Xen host having problems with a disk or disk-access.
Running an install job can only be done as root, so you had to su or sudo for it. When you tried to logon with another account, you where not denied access to the system, but denied access to your home folder. It's safe to say that rules out any problems with PAM.
We once had a problem with similar symptoms. Our Xen Guests tried to write something to disk, wich failed, ultimately resulting in kernel panic on the guest. Before that, the guests behaved much like your server. Turned out a disk with guest-images in the Xen host was failing, which led to guests i/o operations timing out. In some cases the Xen host accepts your disk-writes when it actually has not commited them yet, when the write times out on the host, your server-image will be corrupt.
Three ideas:
Is it posible you have two user with the same UID? Look /etc/passwd
just do this: