1

Howdy... I'm looking to chmod 777 a whole bunch of files. Alternatively, since it's more secure, I could also settle for a chown www:www of these files to make them web accessible.

Now, since I have over 400,000 files, sudo chmod -R 777 ./* and sudo chown -R www:www ./* didn't work at all, returning only with "Arg list too long"

Some googling turned up find and xargs, but this didn't quite work for my file set, since some of the files had underscores in the name. I'm not sure why this would break the script, but it did. The command:

find ./ -name "*" | xargs chmod 777

Here's an anonymized snippet of the directory tree:

files
\- 28934723
   \- file1.xml
   \- file2.txt
\- 34905834
   \- file1.xml
   \- file2.txt
\- 21398230
   \- file1.xml
   \- file2.txt

As far as I can tell from man find, it should recurse into subdirectories automatically, but I am not sure. When I ran the above command, some of the files changed, but the majority of the directories remained the same (same permissions).

Thanks in advance for any help you guys can offer :)

Julian H. Lam
  • 277
  • 4
  • 13
  • 2
    I can't imagine why you want `o+x` on all those files. It's a huge, gaping security hole. It's likely that `664` is all you need - maybe 754, 764 or 774). Only give the **minimum** *necessary* permissions. – Dennis Williamson Dec 07 '10 at 20:26
  • 1
    Try manually chmod 777'ing one of the files that don't change after the find, to see if there's some problem there irrespective of the finding. – Ernest Mueller Dec 07 '10 at 20:29

3 Answers3

4

sudo chown -R www:www ./ and if you don't want the directory owned by www, just change it back.

Chris S
  • 77,337
  • 11
  • 120
  • 212
0

I can't see why the following command line could not work:

find . -print0 |xargs -0 chmod 777

Or simpler, chmod 777 -R .

nicob
  • 84
  • 2
  • -1 for not reading the question, he said chmod 777 returned an error – Ben Dec 07 '10 at 19:31
  • This is not what he said: some files were modified and some not. That could mean that the call to chmod(1) failed, not the `chmod()` syscall. For instance, it's possible that some files had spaces, or dashes at the beginnning of the name. This kind of problem is avoid by `NULL` terminating the filenames (`-print0` option). – nicob Dec 07 '10 at 19:35
  • 1
    Thanks for the reply - the switches -0 and -print0 return an error... – Julian H. Lam Dec 07 '10 at 19:48
0

If you can help it, try to limit the permissions. If you're trying to give full access to www and you're on a redhat system with acl available (may need to remount), try:
setfacl -R -m user:www:rwx the_parent_directory
setfacl -d -R -m user:www:rwx the_parent_directory and repeat with user replaced by group if necessary.

If your argument list is too long and you can't use the full directory, then this will work (but will be slower):
find . -type d -exec setfacl -d -R -m user:www:rwx '{}'; setfacl -R -m user:www:rwx '{}' \;
If there will be files in there as well not covered by directories, you'll need to run it again for those (I'm sure someone will tell me about a switch to setfacl to only do the top directory):
find . -type f -exec setfacl -m user:www:rwx '{}' \;
You can use the same method to do 777 as well (similar to the xargs but I prefer it this way, seems cleaner:
find . -exec chmod 777 '{}' \; as for the underscores, it shouldn't be an issue (it's possible they were being interpreted by the pipe or something), but if they are:
find . -name \*_\* -exec chmod 777 '{}' \;

James L
  • 5,915
  • 1
  • 19
  • 24