Take the 2-minute tour ×

I just noticed that after running

chmod 777 * 

on a directory that has sub-directories in it does what you would expect. It sets the permissions of everything, including the sub-directories to 777. However, if you then decided that you didn't want to do that, and run

chmod 644 *

Now the contents of the sub-directories get set unknown permissions and you cannot change them back.

Why does that happen? Is this the expected behavior, or a bug? Is there a way to restore the file permissions?

Since the files I had were in a zip file in another location, I just deleted the entire directory, and unzipped the zip file again, but I would like to know the causes of this "problem", and it's remedies.

Some additional info, I am running those command on a remote machine over SSH.

share|improve this question

4 Answers 4

Probably best to use find for this sort of thing.

Directories need to be x access , files do not, so different set of permissions.

# Files
find . -type f -exec chmod 644 '{}' \;

# Directories
share|improve this answer
whoops used : not ; on files and is it 755 on dirs? –  user8290 Jan 17 '12 at 23:27
sorry, fixed that now, but it also depends on how much or little access you want to grant (obviously). –  bodhi.zazen Jan 17 '12 at 23:31
Since all the files are of the same type, I run chmod 644 *.php, but find is no doubt a nice way to do it when the files are all of different type. Thanks –  Buzu Jan 18 '12 at 5:05

The way the permission bits are interpreted differ for files and directories. Read info coreutils 'File permissions' and man 2 chmod for details. Why would one want to make everything readable,writeable,executable for owner,group and world?

Since the evidence is gone, I can only guess that after your chmod, you'd lost write access to ., the current directory. This can be fixed by:

chmod u+w $PWD

Then, you can change the mode (permissions) of files in $PWD

By doing the chmod 644 *, you also removed the execute permission from any of the files that had it, so they're no longer executable by any of owner,group,world.

share|improve this answer
Directories also need to be set +x to be accessible. –  Zoke Jan 17 '12 at 23:00
The evidence is gone, but this is something I can reproduce. In fact, at first I did not know what had happened, so I did everything again, and got the same result. I will text your suggestion when I find a free time. Thanks. –  Buzu Jan 18 '12 at 5:09
Your suggestion did not work, but I was able to find the solution to this problem. And in fact, I remember that some time ago, I was thinking that a good way to hide files was to make the directories non-executable, which is what happened here. There is no lost of write permissions to . since 644 assigns read-write to owner, read to group, and read to rest of the world. The problem is the lost of execute permissions. I guess it was pretty obvious, we just didn't see it. –  Buzu Jan 19 '12 at 5:05

When you want to set permissions to directories and sub-directories you should use:

chmod -R

-R, --recursive change files and directories recursively

share|improve this answer
Ah, I know that, I tried it, but did not work to set the file permissions back from unknown to proper permissions on the files in the sub-directories. –  Buzu Jan 18 '12 at 5:10

I found the solution to the problem I had.

First of all, thanks to all of you who posted, your answers were indeed helpful.

The problem is that assigning permission 664 to all the files in the current directory:

chmod 644 *

removes the execute permissions on directories, which need execute permissions in order to work properly. The solution is quite simple. We just need to change the permissions for the directories like this:

chmod 744 dir_name

Where dir_name is, of course, the name of our directory. Once we do that, everything goes back to normal.

share|improve this answer

Your Answer


