5

Trying to replicate the problem described in "/etc/profile permission denied!" where OP of the post in her comments mentions the permission string for her /etc directory being drw-r--r--. I issued sudo chmod 644 /etc and yes that did replicate the problem. Then in live environment I corrected the permission back to 755. (I thought thought that would do no harm, I was just changing the permissions!) With /etc permission reverted back to original, the login problems and others like not being able to sudo were fixed but I'm facing lots of problems in the GUI. Unity doesn't load, no Launcher, no Dash appears! helped to some extent but other problems still persist.

The Question:

What's the reason behind this? I just toggled the execute bit of /etc's permission! Why did that have significant effect on Unity?

Community
  • 1
rusty
  • 16,327
  • 1
    This is why boys and girls, there are virtual machines ;) – Braiam Mar 20 '14 at 15:07
  • 1
    Are you sure the current permissions on /etc are 755? How did you change it in the live environment? Are you sure you did not run something like chmod -R 644 /etc? – terdon Mar 20 '14 at 15:13
  • @Braiam for me the Ubuntu Desktop versions fail to install with VirtualBox.. and usually for tests I used to use live USB with file persistence, but yeah err this time.. @terdon no I didn't do a recursive chmod.. – rusty Mar 20 '14 at 15:16

1 Answers1

3

Right, I tried this (on a VM :-)) and got the same behavior you describe. I changed the permissions on /etc, and rebooted and since I had configured my system to log me in automatically, it attempted to log me in directly and failed.

I don't know enough about Unity's internals to be understand the details but my guess is that when you attempted to login, since the system didn't have access to /etc it couldn't read all sorts of essential files such as /etc/passwd or /etc/group or anything to let it map your username to the appropriate UID and GID. Therefore, upon the attempted login, file details were somehow screwed up.

My guess, and I stress that I'm guessing, is that changes were made to your gconf configuration settings which then screwed with Unity.

I fixed this on my VM by simply deleting all files from my $HOME, removing my user and recreating him. Obviously this is not a solution on the system that you actually use.

The only workaround I can think of is to move/rename all the configuration files and directories:

mkdir old_dotfiles
for file in .*; do mv "$file" old_dotfiles; done

This will move all of your configuration files and directories to ~/old_dotfiles. You can then log out and log in again or reboot and things should be back to normal though you will have lost your config settings. You can then try copying them back again. If this is just a file ownership issue, copying them back should reset the ownership and might fix your problem. If the change was made within one of the conf file, this will break your system all over again so proceed with caution.

Bear in mind that most configuration files will be created automatically so you only need to worry about cases where you have made changes to the defaults. Also, you should make sure that "system" folders of your GUI such as ~/Desktop are correctly set up.

My guess is that this should be enough to return you to a working system, with a newfound love for virtual machines.

Avinash Raj
  • 78,556
terdon
  • 100,812
  • yes moving configuration files does fix the GUI errors.. I ran mv -t /somewhere/else/ .Xauthority .ICEauthority .compiz-1/ .gconf/ .config/compiz-1/ .config/dconf/ to reset things.. but still the question remains. Login was not allowed as any standard user or even guest (in tty you'd be logged in as "i have no name!" awwh programmers with sense of humour!), so I don't think it could break things then.. – rusty Mar 20 '14 at 18:25
  • @rusty not sure I understand. Are you asking why you can't login with no access to /etc? When you set permissions to 644, nobody could cd into /etc since you removed the executable bit which is needed for directories. Therefore all the basic config files were absent. Think /etc/passwd, /etc/shadow, /etc/groups, /etc/profile, the list goes on. None of these files were accessible to the system. – terdon Mar 20 '14 at 18:31
  • the permission issue and hence login problem is not the issue, resetting compiz gconf dconf fixes the "side-effects".. and it's the reason of the side-effects that I want to know. – rusty Mar 20 '14 at 18:38
  • @rusty have you tried comparing the original and new files? Either with a diff or by checking ownership (which you've probably changed now since you move them). Does the problem return if you move the original files back? If not, you know it's a permissions issue, if yes, then things get more complicated. – terdon Mar 20 '14 at 18:40
  • I've had similar problems with compiz/unity in the past.. copying the old files back would not help.. settings in some config files get modified somehow.. – rusty Mar 20 '14 at 18:44
  • 1
    @rusty If you're sure of that, then the problem is likely to be something like @Braiam suggested in chat, that Unity died while setting something up and did not clean up well after itself, a clear bug. If you still have the files, try running a few diffs, they might give more info. By the way, I also tried this with a newly created user, made no changes to his configuration, and was able to log in with no problem after correcting the /etc permissions. So, it is almost certainly dconf/gconf or compiz that's being screwed with. – terdon Mar 20 '14 at 18:48
  • I restored .compiz-1/ and .gconf/ the problem doesn't reappear! ..but with .config/compiz-1/ and .config/dconf/ restored, it does. – rusty Mar 20 '14 at 19:13
  • 1
    @rusty ah, so it was dconf then! Might still have been both mind you but the permissions/ownership was fixed when you copied. My guess is either wrong data written dconf or a corrupted dconf. – terdon Mar 20 '14 at 19:16