Quantcast
Channel: What could have caused all non-root accounts to lose basic file and directory permissions? - Server Fault
Viewing all articles
Browse latest Browse all 7

What could have caused all non-root accounts to lose basic file and directory permissions?

0
0

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.


Viewing all articles
Browse latest Browse all 7

Latest Images

Trending Articles





Latest Images