Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am working on a test server. Was logged in as root and issued

cd /
chmod go-r *

I certainly revoked the write permissions for the users that I had created.

Did I revoke the permissions (r/w/x) from all the groups that were created for processes like mysql, httpd, ftp etc - or do they chown it?

How do I check that?

[Update] I've restarted mysql and apache. mysqld is not running as root. Logs are being written. Checking what else would be a good idea?

share|improve this question
short answer: you are better off reinstalling than trying to fix the types of extremely subtle, often silent problems that this will cause. – strugee Apr 5 '14 at 1:39
@strugee there isn't an -R in there, so this one is easily fixable... – derobert Apr 5 '14 at 3:03
Err, did you did this as "root"? What is the problem you are seeing? – Braiam Apr 7 '14 at 16:11
@Braiam, Err, says "was logged in as root" at the top... – goldilocks Apr 7 '14 at 16:33
up vote 7 down vote accepted

First off, chmod go-r doesn't remove write permissions, it removes read permissions. The contents of / is primarily directories; on directories read permission means you're allowed to list it. E.g., ls /bin will now give a permission denied (except for the directory owner and root, of course the owner is root in this case).

If that was a typo and you meant chmod go-w, then you indeed removed write permission. Likely the only directory which had write permission for group or other was /tmp; you need to fix that.

Thankfully, you didn't include -R (recursive) in your chmod, so this is fairly easy to fix: Just compare ls -l / on the test server to ls -l / on a similar server. Use chmod to set the permissions back as they should be.

Note that chmod will follow symlinks, so if you have any in your root directory, you'll need to confirm them separately.

Finally, you don't appear to understand the Unix permissions model. Each file and directory has one user (the owner) and one group. The owner can have read, write, and/or execute permissions on the file/directory. That's what chmod u=... sets. All members of the group can have the same set of permissions (chmod g=...). Finally, everyone else (others) gets the same set (chmod o=...).


$ ls -l /etc/exim4/passwd.client 
-rw-r----- 1 root Debian-exim 204 Oct 15  2006 /etc/exim4/passwd.client
|^^^^^^^^^|  |||| ^^^^^^^^^^^
|  perms  |  ||||    group
t         |  owner

t the type of file: blank for plain files, d for directories, l for symlinks, c for character devices, p for named pipes, b for block devices, and there are probably a few more I'm forgetting.

acl will be + if there is an ACL on this file, you can use getfacl to see it.

The 1 I didn't label is the link count; if you made a hard link to the file, both names would show 2. Add another, and they'd show 3, etc.

The permissions field is three characters for the owner (user); three for the group; and three for other. The owner (user) can read and write the file, but not execute (since there is a - instead of a x there). Members of the Debian-exim group can read the file, but get no other permissions. People who are neither the owner nor members of Debian-exim get no permissions to this file.

share|improve this answer
Thank you for the detailed answer. I have restored the permissions. Yes, I am a noob wrt Unix Permission Model - will do a good reading before proceeding with the next set of updates. – TJ- Apr 5 '14 at 7:54

chmod go-r * doesn't affect special groups at all. It just affects the rights for the primary groups and the "others". The primary group for everything in / should be root. So that doesn't change anything at all as root can do whatever he wants anyway.

The other accounts usually do not read the contents of the directories in / as they know their paths. Accessing these paths is still possible (due to the x permission).

Whether groups which you have created still have explicit read permission in these directories depends on it whether ACLs are used. If ACLs are present then the ls -l output changes from




The ACL content can bee seen with getfacl.

The main question is: Why should one prevent groups from reading directories in /?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.