DOH! I meant root> CHMOD -R 666 ~

Hey Guys!

Problem: So i've accidentally gone and changed the permissions of all root commands to make them non executable. Including chmod. Darn. What would you guys do in the same situation?
chmod won't help me now! e.g.
root> chmod -R 777 ~
root> "Permission denied - chmod"

Before you say anything, yes, yes, i shouldn't have been directly logged in as root.

(Why have i go this problem? Well, I'm pretty advanced and was trying to change the permissions of my normal user directory (e.g. /home/whatever) as was having permission problems with firefox, and completely forgot that '~' when logged in as root is the root home directory, not the normal users)

Have just tried booting from CD, mounting the drive and forcing 777 permissions on everything just to get it to boot - which it does, then sits with a blank graphical screen with a spinning wheel of doom... :S

Distro: Ubuntu 9.10, on Dell nx6325

Hi
I don't understand. Do you mean you did chmod ? What does chown -R ~ 666 mean?

Am man, how embarrassing. Yes, you're right, i meant chmod rather than chown. Have updated the thread.

Changing permissions from a live CD went well, but the boot didn't. xserver couldn't quite start properly. I'll just reinstall i think... I don't mind, my home directory is on a separate partition!

I have no idea of what were you trying to "fix" with this. Next time ask before doing massive operations like this one because I don't think you knew the implications of what you were doing. This would have caused you problems even as normal user.

In any case, you are making yet another wrong assumption here. For root, '~' or '$HOME' is '/root/', and not '/'.

Commands like chmod live usually in /bin, /usr/bin/, /sbin/ and /usr/sbin, so changing all the permissions under /root/ will not affect the bin directories at all. That means that you are either not telling part of the story or (what's even worse) that there's yet another typo or mistake that you made and you don't know about.

I'd start by doing ls -l in /bin and /sbin. If the files in there do not have the +x permission, then I think you can start baking up and reinstalling your OS.

If you really did this, that's another reason to reinstall. You must know that, when you do this, there's no way to restore the permissions to a previous state, unless you backed them up previously. Files in *nix do have a given permission scheme because of a reason.

Hi,
Well if your /home is safe, reinstalling will be easier. Or maybe somebody else have a simpler solution.
Any way it is dangerous to play with permissions..
-Cheers
indiajoe

Hey guys, thanks for the replies on this.

Yea, my main sticking point is that Unix has no way of getting back to the permissions you had before screwing it all up like i did! (i wonder if there's any distro out there that might have thought of including this feature).

Reason i got myself into this mess is that i wiped my harddrive but kept my old ubuntu 9.09 /home directory partition. However, when 9.10 was installed around that, it didn't like some of the settings from 9.09 (kept in /home). So, i was getting to the point where ubuntu wouldn't save Nautilus settings, Firefox had "Could not initialize the browser's security component" error etc.

Since i couldn't change /home/myusername permissions due to ".gvfs access denied" errors, i alt+ctrl+1 into CLI and did the old and thinking '~' would be /home/myusername. It flashed errors on the screen before not even allowing me to chmod anything... I swear that's all i did - so no idea why it was coming up with "permission denied - chmod" after only affecting the /root directory... hmm.

After going into live cd I mounted the drive and just tried logging in as root and doing which again is WRONG as i'd only changed /root permissions, not / permissions.

Uck what a mess! Oh well, halfway to reinstalling now though.

Well, you are supposed to do backups before doing potentially dangerous things. You also have to login to root, the problem is that most users don't see that as an administrative task, but an habit. When login as root you should always imagine a big red button on the center of your screen telling you:

Yes, I understand that it's potentially dangerous and I refuse to complain if I blow up my box case.

However, I see how you got confused with su, it's perfectly understandable so don't worry too much. As long as there wasn't any important thing on the box, it's just a learning experience.

Some fs's offer the possibility to do snapshots, lvm does as well, saving you time and space when it comes to backups. This is nothing to do with your distro.

You can always use a home made solution, for example:

Will save the permissions from /path/to and everything below to a file called chmod.txt. You can use this to restore them at any given point of you hose your os:

Largely untested, it's just an idea. You should never run any code you can't understand at least at a basic level (and that includes mine ).

It's usually better to just pick the needed config files one by one. Some of them will be incompatible and can break your tools in many creative ways, even if permissions and ownerships are ok.

By the way, and in any case, what you wanted here is to adjust the owner:group pair, and not the permissions probably. Your user probably had a different UID on the new system, that's why. Setting permissions to 777 for everything is usually not a good idea, and some programs will complain when such a permission scheme is instantiated (ssh comes to my mind).

Hi,
I don't think it will be difficult to write a shell script to store all the permissions of the entire files in the hardisk. And again another script to read from what the first script has stored to assign it back.
______Algorithm_____
1st Script___
Use some thing like ls -Rl / to get all the file names in the hardisk and their permissions, owner and group.
Save them to some text file, and keep it safe for future..
2nd Script___
To be run when disaster strikes..
Recursively read out the permissions and other details from our stored text file and assign it to them accordingly using chmod. (awk will help in reading out what we want, and chmod will implement it.)
---------
Only question is whether it is worth doing.
-Cheers
indiajoe
------------------------------------------------

Next time you need to change perms, consider using symbolic mode (chmod +rw) instead - that would have saved you because it wouldn't remove execute perms.

Also (as you've already learned), if you are using -R, it's smart to be specific about the target: no "~" , no "." without doing "pwd" first, no wildcards unless you really need them and have vetted them with "echo yourwildcardpattern" - because we ALL screw up.

You mentioned resetting perms?

(http://www.cyberciti.biz/tips/reset-...ermission.html)

might help (wouldn't have helped this mess though).

I had recently had a customer do something similar and had whined about it at The cure for everything - chmod 777 :-)

I wouldn't even call it a script, look at my previous post, a simple find command suffices. Please, don't parse the ls output like that, it's not a good thing:

http://mywiki.wooledge.org/ParsingLs

If you save the details in a sane manner you don't even need additional parsing, example also in my previous post.


Well, it certainly doesn't take much time to do so, and it can save you a whole reinstall in case of a silly typo while running chmod as root. You can use this in cronttab or a cron script to backup them at regular intervals, use something like $(date +%Y%m%d).perms.backup for the file name, and you can save many backups without erasing the previous ones, in case you need to check for reference. It will be just a list in plain text format, it doesn't take space, and in any case it will compress greatly even with gzip.

As an aside, the hidden "GNOME virtual file system" directory (.gvfs) is a "special" object for which even "root" can't change permission or ownership. So, even if you had used the correct directory name, the chmod would have still "barfed" when it got to .gvfs.