5

I wrote a script to change permissions on all files in a directory:

#!/bin/bash

files=`find "$1"`

for f in $files; do
    chown "$2" "$f"
    chmod 600 "$2"
done

Obviously, the second argument to chmod should be "$f" instead of "$2". However, when I ran the script (on a small directory) I also forgot to include the second argument, which should have been "dave:dave". Now, all the files in the directory are completely messed up:

~ $ ll Documents/                                                                                                      
ls: cannot access Documents/wiki.txt: Permission denied
ls: cannot access Documents/todo.txt: Permission denied
ls: cannot access Documents/modules.txt: Permission denied
ls: cannot access Documents/packages.txt: Permission denied
total 0
-????????? ? ? ? ?            ? modules.txt
-????????? ? ? ? ?            ? packages.txt
-????????? ? ? ? ?            ? todo.txt
-????????? ? ? ? ?            ? wiki.txt

Running sudo chown dave:dave Documents/* and sudo chmod 600 Documents/* throws no errors, but the files remain unchanged. I know I can sudo cat each file into a new file, but I'm curious how to fix the permissions on the original files.

  • 3
    Searching for the dupe, but you need to change the permissions on Documents as well, not just the files inside it. – Michael Homer Feb 15 '16 at 6:23
  • 2
    Doh - the directory was 600. What a dumb mistake... – Big McLargeHuge Feb 15 '16 at 6:24
  • 1
    Hey, we've all done it at least once. This is why find $1 -type f is better in this situation than find $1 – Steve Bonds Feb 15 '16 at 7:03
5

In addition to the answers given in the comments, you should also note that your script will break on any filenames with spaces in them.

You can do all of this in a single command using find, rather than trying to parse a list of filenames output from find. Much more robust; handles filenames regardless of special characters or whitespace.

find "$1" -type f -exec chown "$2" {} \; -exec chmod 600 {} \;

Note that if the chown fails on a given file, the chmod will not be run on that file. That's probably the behavior you want anyway.


Since you already ran an erroneous command that removed execute permissions from your "Documents" directory, you need to add back execute permissions:

chmod u+x Documents

If there are more directories that erroneously had execute permissions removed, you should be able to fix them with:

find Documents -type d -exec chmod u+x {} \;

I don't think you'll need this, though, as once execute permissions were removed from "Documents" then none of its subdirectories would be accessible, so execute permissions wouldn't have been removed from them.

| improve this answer | |
  • 1
    You're right, but the answer was to chmod u+x the directory. If you add it to your answer I can accept it. – Big McLargeHuge Feb 18 '16 at 21:47
  • @DaveKennedy, fixed. :) – Wildcard Feb 18 '16 at 22:06
2

The one time I saw files with such weird permissions, it was on a seriously messed up filesystem. A round of fsck(8) got much of them back to relative normality, but many were still heavily corrupted. I believe it was due to a hardware problem (got the good files off the disk, and tossed it).

| 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.