Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This should be simple, but I am not getting it to work in test.

An torrent application I am using (CLI based) does not yet have the ability to define the user/group/permissions of the files it downloads. It also enjoys setting the permissions of the files in a way that they can't be modified much.

I would like to use set-uid and set-group-id to solve this.

Given a path of something like this: /Volumes/torrents/movies

I would like the "movies" directory to allow all users on the system full read and write access. Files should not be executable, but of course, the directories will need to be in order to open of cd into them. I trust all users on this system, though I will refrain from execute bits on files to prevent accidental mistakes.

Anything saved/stored within "movies" should inherit the user/group/permissions of movies, and trickle down to all sub directories and files. With this, I should not have to worry about the lack of permissions setting feature of the application. If movies is set to rw for foo:bar and user the_user comes along and puts a file in movies, I would expect the files to become rw foo:bar.

Thanks. I have tried this a few different ways, and I am coming up short. I rarely use set-uid and set-group-id or the sticky bits.

share|improve this question
What OS are you using? – Moab Jul 4 '10 at 23:53
Apparently Mac OSX, based on the "/Volumes/" path. – Hello71 Jul 13 '10 at 0:50

The most you can do is to make the directory setgid, which will make files and directories created in it acquire the group owner of the directory. However, the setgid bit will not be inherited, which means that anything beyond the first layer will not have the group ownership applied. The only way to resolve this is to use cron or incron to apply the permissions changes as appropriate.

share|improve this answer
Are you certain about that? Everything I have researched about this states that is not the case – user17245 Jul 5 '10 at 7:18
Which part of that article contradicts what I've said? – Ignacio Vazquez-Abrams Jul 5 '10 at 7:39

I'm guessing based on your previous questions and the "/Volumes" folder you've mentioned that you're using Mac OS X.

I got a tip from this article which shows how to create an AppleScript and attach it as a folder action which sets permissions on all files dropped into the folder. Here is the script as I tested it just now:

on adding folder items to this_folder after receiving added_items
    tell application "Finder"
        set fold_name to the name of this_folder
            repeat with i from 1 to number of items in added_items
                set new_item to item i of added_items
                set the item_path to the quoted form of the POSIX path of new_item
                do shell script ("/bin/chmod -R a+rw " & item_path)
            end repeat
        end try
    end tell
end adding folder items to

Type this into the AppleScript Editor then save it in /Library/Scripts/Folder Actions Scripts. Then right-click on the folder and choose "Folder Actions Setup..." (or "Attach a Folder Action" for Leopard or older). Attach your script, and test it out. Drop an item into the folder and it should recursively chmod everything to allow read/write for everyone.

This works if you drop anything directly into the folder, including another folder: all the contents recursively get updated. However, if you drop files into an already-existing subfolder, then the folder action doesn't get called. I haven't figured out a way to fix that.

share|improve this answer
Thanks. I would probably just lean on using launchd and running a quick chown foo:bar /path/to/files/* Right now I am trying more to learn about setgid and setuid as much as I can. – user17245 Jul 5 '10 at 7:22

The Wikipedia page linked in another answer does contradict the answer itself: the set-GID bit is normally inherited. This is certainly true on Linux, and I believe on Solaris. However, it doesn't appear to be true on Mac OS X. The manual page seems to talk more about ACLs than normal permissions, so perhaps you will have some luck with the file_inherity and directory_inherit permissions in combination with the traditional ones.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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