Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Not to state the obvious, but this is a prime example of why you should ALWAYS use the root account with extreme caution, and even then, only in a small number of specific situations, such as if you are installing new software packages. If you are frequently run as root, or run as root as a matter of habit, it is trivially easy to hose your system.
In any case, without knowing which distro you are running, the generic, safe recommendation I can offer consists of 2 steps:
1. Backup your important data
I will defer to people with greater knowledge, but once you change a file(s) permissions, you lose the ability to restore them to their previous value. Thus, a reinstall is the only sure way to return them to their appropriate values. Again, I'll emphasize that others here at LQ may have superior experience and may be able to offer alternative suggestions, but if I were in your shoes I would just go for the reinstall. -- J.W.
thx for the reply. I knew i shouldn't have been goofing around in root. I had heard it, and now I have learned the hard way. I suppose a reinstall wouldn't be so bad. I don't have much configured yet anyway.
I'll wait another day or so to see if any repies come.
I was under the impression that chmod -r ugo-x /whateveryouscrewedup would revoke executable permissions for those files. But then again, my linux knowlege dosen't warrant a moderator position on a major forum. =)
Travers, you are correct, however, that action would also revoke executable permission on files that were executable before the change. Making all files in /bin unexecutable would cause some rather major system problems.
Everything you use on a linux system is in /bin /usr/bin /sbin and the like. If you chmod -x it, you revoke execution on everything. Unfortunately, this is very bad, condsidering bash itself lies in /bin/bash. You'll render all utilities virtually useless including ls, cp, mv, bash, sh, tcsh, etc.. etc... and the really bad thing is, you won't even be able to change it back, because chmod is a program that lies (guess where), hence rendering it useless as well.
As btmiller points out, the issue with making mass changes to the permissions on a set of files is that there is no guarantee that you will set things back the way they were previously, and regardless of whether it looks like it it's OK, you would be making a huge assumption.
To illustrate, let's use 2 files with the following permissions, which we will then change en masse. The results would probably be something along the lines of:
-rw-r--r-- somefile 2
During: (chmod as root, per the original post)
Proposed fix (chmod ugo-x, per the recommendation)
That would restore "somefile2" to the correct level but would break "somefile1", which I would consider to be just as bad if not worse than the original problem. Hence, the safest thing to do IMO would be to reinstall. Granted, a reinstall is a pretty severe solution, however, I would be comfortable in stating that it would be a sure-fire way to restore the proper set of permissions.
Finally, I'll reiterate the point that this situation is an excellent lesson in why running as root is a poor idea. -- J.W.
Yes, I realize that I was a fool. Well live and learn. It gives me a good idea for a prog though.... Run in and it will store all permissions. Run in a different mode and restore permissions. Then there are always those files that get added inbetween.
Building a utility like that would be a useful exercise, however, I would caution that changing permissions is not really an action that should be taken on a frequent basis, and similarly, if it is needed, it typically is done on a single file rather than a group. My main point is just to be careful when performing these sorts of system level actions. Good luck with it in any event -- J.W.
The OP stated in his first post that he accidently made all the files in /bin executable. Seeing as they are executable normally, I would like to pose my original question - What's the problem?
Clearly he may have meant something other that what he said. But he may also have been mistakenly under the impression that he caused a change to his system when in actuality he did nothing at all.
I would agree that changing file permissions on an entire directory is usually a difficult thing to undo correctly - and clearly something to avoid if possible. A glance at my /bin directory, however, showed 2 file types: executables with 755 permissions and symlinks with 777 permissions.
Given a worse case scenario where the OP had made the entire contents of /bin NON executable, the suggestion of chmod -R 755 bin would have corrected the entire problem. Of course, the symlinks would then be 755 and not 777, but they would still be executable by all - just read-only. A little time changing these symlink permisions would have returned the system to normal.
While this particular poster did not mind having to reinstall, I think that an attempt at repair before doing this was at least worth trying. Perhaps getting the output of ls -l on /bin would have been a better start.