root> chown -R 666 ~
DOH! I meant root> CHMOD -R 666 ~
Hey Guys! Code:
root> chmod -R 666 ~ 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? |
chmod
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! |
Quote:
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. Quote:
|
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 Code:
sudo -s Code:
chmod -R 666 ~ After going into live cd I mounted the drive and just tried logging in as root and doing Code:
chmod -R 777 / Uck what a mess! Oh well, halfway to reinstalling now though. |
Quote:
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: Code:
find /path/to/ -type f -or -type d -exec stat --format="%a %n" "{}" \; > chmod.txt Code:
while read LINE; do PERMS=${LINE%% *}; FILE=${LINE#* }; chmod $PERMS "$FILE"; done < chmod.txt Quote:
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? Code:
rpm -a --setperms 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 :-) |
Quote:
http://mywiki.wooledge.org/ParsingLs Quote:
Quote:
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.
|
All times are GMT -5. The time now is 05:23 PM. |