Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the '10.4: Share an iPhoto library among multiple users' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.4: Share an iPhoto library among multiple users
Authored by: david-bo on Sep 10, '05 10:10:22PM

Wouldn't just changing your umask take care of this issue?


[ Reply to This | # ]
10.4: Share an iPhoto library among multiple users
Authored by: elmimmo on Sep 11, '05 06:23:42PM

Yes, but that would affect all of your newly created files, not just the iPhoto Library. To those not knowing the "umask" sets what permissions new files are created with. Taking into account that by default OS X creates a new different group for each user account, you would need to set your umask to allow write access to all your files to all users, which not everybody wants (unless your tinkering goes further, which involves playing with Netinfo manager, chmod'ing and chown'ing preexisting files in your home folder, blah, blah… not for the faint of heart).

[ Reply to This | # ]
10.4: Share an iPhoto library among multiple users
Authored by: elmimmo on Sep 11, '05 06:25:33PM

Oops! I meant iTunes Library in "not just the iPhoto Library".

[ Reply to This | # ]
10.4: Share an iPhoto library among multiple users
Authored by: crispyking on Feb 02, '06 02:57:07AM

Yes, I use umasks to accomplish the same thing and it works great.

The trick is that Mac GUI Apps don't respect the shell's umask setting, so you need to add it to the .GlobalPreferences database by doing: 'defaults write -g NSUmask 2' There's a MacOSXHint for 10.3 (search for NSUmask).

It can actually be a good and secure thing to have a umask of 2 always (i.e. make things group writeable by default) if you have groups set up properly. Recent releases of OSX (since 10.3 I think) create a unique group for each user by default so a umask of 2 works great to keep a user's files private, and facilitates sharing in groups. Just change the group ownership of a directory and start using it for group projects and everything just works like you'd expect, and everyone in the group can write files.

[ Reply to This | # ]
umask, NSUmask, etc.
Authored by: sjk on Feb 02, '06 12:12:14PM
Just wanted to add that using "umask 2" and "NSUmask 2" doesn't guarantee files will always be created group writable.

Also, if a directory is group writable any member of its group can create/delete/rename files in that directory, but not necessarily modify them because of lacking explicit write permission. In that case you may need to change permissions of any preexisting files to be group writable.

An app might modify a write-protected file in a group-writable directory by renaming the original file, writing a new version, then deleting the original. That new version will normally be owned by the user running the app. Sometimes the new version will properly inherit permissions via umask but there are exceptions. Version control software like RCS can operate this way, relying on directories being writable rather than the individual files they contain.

The rules for traditional Unix-style directory and regular file permissions/ownerships are fairly easy to understand. What's tricky is getting them to properly behave and cooperate consistently, especially over entire filesystems. For example, the big limitation with umask is it's a global setting rather than being per-directory. ACLs can help but add more complexity and management issues.

Personally, I prefer managing a smaller number of group writable directories than a larger number of group writable files. If someone can't modify the file in a group writable directory I might tell them to make a copy of it, modify that, then replace the original with the copy instead of having to make the original file writable. And sometimes it's an advantage that the file ownership then changes to the user who last modified it. But most apps only care about file permissions when attempting modifications and ignore possibly more liberal directory permissions.

As I've written before, the original Unix permission scheme wasn't designed for scaling to handle the huge numbers of files/directories we manage nowadays yet we're still stuck using it.

[ Reply to This | # ]