89

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
  • 3
    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. Jul 19, 2016 at 21:47

5 Answers 5

112

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

chmod -R -x+X -- 'folder with restored backup'

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

See Stéphane Chazelas's answer for a solution that uses find to really not touch folders, as requested.

9
  • 4
    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, 2016 at 23:16
  • 3
    Also see Edward's answer about exception for BSD
    – fikr4n
    Jul 20, 2016 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, 2016 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, 2017 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, 2018 at 16:57
20

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.

2
  • 1
    Nice read. Thanks for doing the research into this.
    – user179983
    Jul 21, 2016 at 2:43
  • 1
    Nice comparison, but I wonder if he difference is between Linux and BSD or between Gnu chmod and BSD chmod: Is the difference in the kernel or the process. Jan 29, 2021 at 7:16
14

One way to do it:

find backup -type f -exec chmod 0644 {} +
7
  • 10
    This could wind up adding or removing permissions you didn't want to change. Better to use chmod a-x {} Jul 19, 2016 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. Jul 19, 2016 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? Jul 20, 2016 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. Jul 20, 2016 at 5:36
  • 2
    The question specifically asks for how to remove exec permissions on all files, nothing else. chmod a-x does that, chmod 0644 does something else. If you were worried about others modifying your files then they wouldn't have been 777 to being with.
    – N.I.
    Jul 20, 2016 at 11:52
14
 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).

4

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 

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .