I made a backup to an NTFS drive, and well, this backup really proved necessary. However, the NTFS drive messed up permissions. I'd like to restore them to normal w/o manually fixing each and every file.

One problem is that suddenly all my text files gained execute permissions, which is wrong ofc. So I tried:

sudo chmod -R a-x folder\ with\ restored\ backup/

But it is wrong as it removes the x permission from directories as well which makes them unreadable.

What is the correct command in this case?

  • 1
    Meta: I've never understood why Unix systems add the execute bit to files mounted from DOS or Windows file systems. It's not like anybody's ever going to execute those files. I generally add "noexec" to my mount options wherever practical. – Edward Falk Jul 19 '16 at 21:47

If you are fine with setting the execute permissions for everyone on all folders:

chmod -R -x+X *

The -x removes execute permissions for all
The +X will add execute permissions for all, but only for directories.

See below for a solution that uses find to really not touch folders as requested.

| improve this answer | |
  • 2
    The command I eventually used to restore permissions to normal: `chmod -R a-x+X,u-x+rwX,go-wx+rX directory/ name` – gaazkam Jul 19 '16 at 23:16
  • 3
    Also see Edward's answer about exception for BSD – fikr4n Jul 20 '16 at 7:37
  • 4
    This fails the "without touching folders" requirement. What if execute (maybe for world) has been intentionally removed on some directories? You should not be adding it. – Ben Voigt Dec 7 '16 at 17:06
  • 4
    this did not work on Mac. Moving the -R flag to the beginning will make this work in both linux and Mac terminals. chmod -R -x+x * – JoeMoe1984 Jun 15 '17 at 21:38
  • 2
    Actually with the correct order it runs on OSX, but it doesn't actually have the desired effect. You have to do it as two separate steps: chmod -R -x * && chmod -R +X * – Timmmm Oct 10 '18 at 16:57

Ok, I re-read the "chmod" man pages for Mac OS X, BSD, and Linux, and did a few experiments. Here is what I learned about symbolic modes. It can get complicated, but it's worth understanding:

  • The general form is clause[,clause…] where:
  • clause := [ugoa][+-=][rwxXstugo]
  • [ugoa] (who) (specify multiple) means set the permission for user, group, other, or all. If not specified, the default is 'a', but the umask is in effect.
  • [+-=] (action) (specify one) means:
    • + means add the specified permissions to the permissions already in effect
    • - means remove the specified permissions from the permissions already in effect
    • = means set the permissions to the specified permissions, clearing all others
  • [rwxXstugo] (permission) (specify multiple of rwxXst OR one of ugo) sets the permissions for the specified user(s) as follows:
    • r — read
    • w — write
    • x — execute/search
    • X — execute/search iff directory OR any execute bit was already set.
    • s — suid or sgid
    • t — sticky
    • u — copy user permission
    • g — copy group permission
    • o — copy other permission

So for example, a+x would make a file executable by everybody. a+X would make a file executable by everybody IF it had been executable by anybody.

a+x would make a directory searchable by everybody. a+X would also make a directory searchable by everybody.

The key difference between BSD and Linux is that with BSD, the determination is made based on the file's permissions before chmod was executed. While with Linux, the determination is made immediately before the +X clause is executed.

So with BSD, the combination a-x,a+X would remove execute/search permission and then make a directory searchable by everybody, and make a file executable by everybody if it had originally been executable by anybody.

With Linux, a-x,a+X would remove execute/search permission and then make a directory searchable by everybody, while leaving a file executable by nobody.

Here's a concrete example: on a BSD machine: a directory, an executable file, and a non-executable file:

drwxr-x---  2 falk  staff  68 Jul 19 18:01 fee/
-rwxr-x---  1 falk  staff   0 Jul 19 18:01 fie*
-rw-r-----  1 falk  staff   0 Jul 19 18:01 foe

Observe that both the directory and "fie" are executable/searchable by the user, but not by others.

Now we execute chmod a-x,a+X *. The first clause will strip the execute/search bit from all users for all files, but the second clause will add it back for both "fee" and "fie". "fee" because it's a directory, and "fie" because it had at least one executable bit to start with.

drwxr-x--x  2 falk  staff  68 Jul 19 18:01 fee/
-rwxr-x--x  1 falk  staff   0 Jul 19 18:01 fie*
-rw-r-----  1 falk  staff   0 Jul 19 18:01 foe

I had the same result executing chmod -x+X.

Conclusion: Jak Gibb's solution will work on Linux, but for BSD, you would need to make two passes.

I didn't test this on SVr4 or other Unix variants.

| improve this answer | |
  • Nice read. Thanks for doing the research into this. – Jak Gibb Jul 21 '16 at 2:43

One way to do it:

find backup -type f -exec chmod 0644 {} +
| improve this answer | |
  • 6
    This could wind up adding or removing permissions you didn't want to change. Better to use chmod a-x {} – Edward Falk Jul 19 '16 at 21:45
  • 2
    @EdwardFalk chmod a-x {} could also end up removing permissions you didn't want to change, and it could leave files world-writeable. The point is, 0644 is a "generally reasonable" compromise. The OP should, of course, also engage brain before applying solutions from the Internet on his computer. – Satō Katsura Jul 19 '16 at 21:49
  • 4
    "a-x" removes execute permission for user, group, other, and leaves the other permissions unchanged, as far as I know. Do I have that wrong? – Edward Falk Jul 20 '16 at 0:31
  • 1
    @EdwardFalk No, you're right. But you don't know what the set of files really is, and you also don't know what the permissions before chmod are. If the backup files contain scripts and binaries, removing x from them is wrong. If the permissions before chmod are 0777 then chmod a-x will still leave them 0666, which is probably not what you want. What I'm saying is that chmod 0644 is better heuristics, not that chmod a-x is wrong. – Satō Katsura Jul 20 '16 at 5:36
  • 1
    @NajibIdrissi Except when, you know, they changed to 0777 when you copied them on a foreign filesystem that doesn't have UNIX permissions. Which is exactly what the OP did. – Satō Katsura Jul 20 '16 at 14:42
 find backup ! -type l ! -type d -exec chmod a-x {} +

Would remove execute permission to files that are not of type directory (as you requested) nor symbolic link (symlinks are generally always rwxrwxrwx, and chmod would affect the target of the symlink on them).

Note that:

 find backup -type f -exec chmod a-x {} +

would only change the permission of regular files. That would exclude directories and symlinks, but also devices, named pipes, sockets and possibly others depending on the system (though in the OP's case of a backup of a NTFS file system, those would be unlikely to be present).

| improve this answer | |

In zsh, use the glob qualifier . to match only regular files (not including symbolic links), and D to match dot files:

sudo chmod a-x folder\ with\ restored\ backup/**/*(D.)

If the command line is too long, you can use zargs:

zargs -- folder\ with\ restored\ backup/**/*(D.) -- sudo chmod a-x 
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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