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

Avoid drop box file permission issues Network
On the Macs in my home, we have permissions issues when copying files into other users' Drop Boxes. If my wife, for example, sends me a file via the Drop Box, and I move it to another folder, the permissions are not appropriate for me -- files only open as read only, because the ownership is not correct. So to use files sent this way, we have to Option-drag them from the Drop Box. This creates a copy, with the appropriate ownership.

I'm not sure if this happens to others, but for us, it's an annoyance. As long, however, as we Option-drag, we can use the files as we want to.

[robg adds: I don't see this issue here, and in talking with Kirk about the problem, we compared the Permissions section of the Get Info dialog for our Drop Box folders. On my machines, including a brand-new iMac that's fresh from the factory, there are two entries for my user in the Permissions section -- one with Custom privileges, and one with Read & Write privileges. On his machines, the Custom permissions entry is missing.

I found this thread on our forums that talks about the same problem ... what makes this really odd, though, is that it doesn't seem to be universal, as it's working well here. If anyone has an explanation/permanent fix for this odd behavior, please post in the comments -- repairing permissions doesn't help, because that won't change things within the user's folder (and yes, Kirk tried it anyway).]
    •    
  • Currently 2.56 / 5
  You rated: 2 / 5 (9 votes cast)
 
[34,636 views]  

Avoid drop box file permission issues | 23 comments | Create New Account
Click here to return to the 'Avoid drop box file permission issues' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Avoid drop box file permission issues
Authored by: tempel on Oct 08, '08 08:42:01AM

Just a wild guess: If there are two permission sets for the same user, could it be that one of them is from the standard unix permissions data and one from an ACL? If so, maybe ACLs aren't enabled on those computers, or something prevents them from working.



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: xanadu420 on Oct 08, '08 08:54:13AM
Well running a sudo chown -R yourusername ~/Public/Drop Box/ would change all the files in your Drop Box to the proper ownership. I don't know much about applescript, but could you make a script that runs that command every time something is put into that folder? I don't know if you can do that because changing the ownership requires a sudo and you would have to type in your password.

[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: sojourner on Oct 08, '08 11:47:33AM
thanks for this hint! i love using drop boxes but hadn't found a workaround for this issue. i use hazel instead of folder actions, and hazel does allow you to use shell scripts. i'm not sure how you would handle this from a non-admin account, though.

[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: thehigherlife on Oct 08, '08 12:18:04PM
read up on how to edit the sudoers file.

http://www.gsp.com/cgi-bin/man.cgi?section=8&topic=visudo

[ Reply to This | # ]
Authentication using AppleScript
Authored by: Fenton on Oct 08, '08 01:23:54PM

Just an addendum. In AppleScript you can bring up the authentication dialog with the phrase:

do shell script "command " with administrator privileges

You can also include your password, to avoid the dialog, using the syntax:

do shell script "command " password YourPassword with administrator privileges

Though it would be kind of a security risk having such a file laying around.

---
FileMaker Developer
San Diego



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: tubadood on Oct 17, '08 02:05:58AM

Although quite kludgy, if you wanted to avoid the superuser authentication issue while executing an applescript, you could write a folder action to attach to your dropbox that duplicates the file, thereby changing ownership to you (as you're doing manually now), then overwrites the original file with the copy.

Ick. Kludgy indeed, but it would work.



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: cibi3d on Oct 08, '08 08:57:25AM

xanadu420, I think that you are talking about "Folder Actions"... I've only used them once and I wasn't very happy with it, but I've seen a lot of things done with that.



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: rrwright on Oct 08, '08 09:13:30AM

I am a consultant and constantly run into this very problem on many different people's Macs. It's nice to have a work-around! I don't know what the cause is, but the problem is certainly real and doesn't seem to be the result of messing up a good configuration.



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: graphicgeek80 on Oct 08, '08 09:17:34AM

I have the same issue in my office when transferring files between computers. I actually came up with the same solution (great minds think alike). But would love to fix the underlying problem, the fact that it happens at all.



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: gctuser on Oct 08, '08 09:26:28AM

change the umask-settings to give group read/write permissions on your files. search the forum for the answer to this question or use a utility like tinkertool.



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: TravisD on Oct 08, '08 09:34:06AM

This sounds a lot like a classic Unix issue. I'm completely guessing here, but *nix basically always uses the numerical UID/GID "under the covers". The nice human-friendly Username is just show to you in the utilities that need to, and is looked up on the fly out of whatever mechanism the system is using to store such details.

Now what happens is that when you move files around, unless the program handling the ingestion of the file takes care of it, the file retains it's original UID/GID. You can see this if you untar a file archive that was created on another system - the files will end up being owned by whatever UID/GID they were owned by on the other system, which may or may not map to an actual user on the destination system.

I'm thinking here that in one case, both users actually have the same UID since they were the first users created on their respective systems. In the other case, perhaps the Logins were created in a different order, or each was "first' on their respective system.

First User is created and given UID 501. Second user is created and gets UID 502. As long and the files are transferred from the First User on each system, the UID matches and things are fine. If not, ownership issues come up.

This is why some programs that move files between systems (such as Samba) support changing ownership of any transferred files to some designated user, possibly also defaulting to a particular permission set as well.

Total speculation here, but figured it might give you an angle to work on.



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: kirkmc on Oct 08, '08 10:03:19AM

No, they're not both 501; that's something I checked. In fact, my user (kirk) is 501 on my Mac, my wife's Mac, and my Air. On my son's Mac, he's 501. And this problem happens between all of them except the Air.

Kirk

---
Read my blog: Kirkville -- http://www.mcelhearn.com
Musings, Opinion and Miscellanea, on Macs, iPods and more



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: ghay on Oct 08, '08 02:08:54PM

The users won't have the same UID on the same machine, and I'm fairly sure in the case of mounted volumes, you are authenticated as a user on that box, so have the permissions of that user, or you have "ignore ownership" turned on and everything is owned by the unknown user.

I think it is highly more likely that there is an ACL at work on the drop boxes.
I would remove any ACLs from the drop boxes, et al

sudo chmod -RN /path/to/folder

Then try again.



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: kirkmc on Oct 08, '08 02:12:44PM

The users _do_ have the same UID on different machines, because I set up my "kirk" user first on all my Macs. For example, if I connect from my Mac Pro to my Air, I can go into kirk's drop box, because it's 501 with the same password.

Kirk

---
Read my blog: Kirkville -- http://www.mcelhearn.com
Musings, Opinion and Miscellanea, on Macs, iPods and more



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: ghay on Oct 09, '08 03:19:35AM

You misunderstand - you have authenticated with the other box.

If I go and create a new account on another mac - I just have to test this very point - the user UID is 502, yet when I login to the mac and authenticate as that user, all the ownership shows as 501 - because that's what I am on the local box.

It has to work this way due to the mount point at /Volumes as if I suddenly had the foreign UID, my local account couldn't access anything on the remote box.

It simply doesn't matter what the UID is on the foreign box, when mounted as a network drive it will either be owned by unknown or your local user.



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: ghay on Oct 09, '08 03:20:42AM

And I really do think it is an ACL issue anyway



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: Dr. T on Oct 08, '08 09:45:15AM

I don't know the cause of the problem, and all my attempted workarounds failed. I've completely abandoned Drop Box folders in my household with three OS X Macs. I now move files using Screen Sharing and an external hard drive with "Read & Write" permissions given to everyone and "Ignore ownership on this volume" checked. All three Macs can mount the volume, copy files from it, and add files to it.

If Apple ever fixes the Drop Box permissions problem, I will happily go back (but I'm not holding my breath).



[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: beauh on Oct 09, '08 12:45:17AM

This is due to ACLs. 10.5 by default puts an ACL with inheritance for the user on the drop box folder, this ensures that even if they aren't the POSIX owner of a file (they won't be), they still have control over the file. Any files copied into the dropbox will inherit the ACL. However, files get ACL inheritance during creation, hence the "copy" solving the problem (a new file is spawned), but not the move.

Keep in mind that if you drag a file into a different directory on the same volume, default is move, not copy; if you do this over a file share, the operation will likely involve the spawning of a new file and trigger inheritance.

You can see the ACL using ls -ael /Users/myUser/Public... There are a number of reasons that the ACL might not have been applied to the Drop Box folder, upgraded from 10.4, manual manipulation of home directory files, etc...





[ Reply to This | # ]
Avoid drop box file permission issues
Authored by: beauh on Oct 09, '08 12:50:58AM
Avoid drop box file permission issues
Authored by: kirkmc on Oct 09, '08 09:25:40AM

This works. Thanks.

It turns out that none of the drop boxes in question have ACLs. Why, I don't know...

Kirk

---
Read my blog: Kirkville -- http://www.mcelhearn.com
Musings, Opinion and Miscellanea, on Macs, iPods and more



[ Reply to This | # ]
Why this Happens
Authored by: gerritdewitt on Oct 09, '08 08:45:43PM
Yes, you may see this problem from time-to-time, but newly-created user accounts on a Mac OS X 10.5.2 or later Leopard system should not exhibit it. To be able to explain what's going on, you need to know a few of the rules that Mac OS X uses for setting file permissions:
  • Leopard systems automatically enable access control lists (ACLs) on the startup disk. Tiger systems do not.
  • Newly-created Leopard accounts are given the primary group of staff. This is also the case for Tiger Server and Leopard Server systems, but not for Tiger client. Tiger client uses what's called a "GID per UID" system, where a new group is created for each user. (Throughout these examples, we'll use staff as the primary group for all users, although that will be different for local accounts on a Tiger client.)
  • POSIX permissions are "regular" UNIX permissions for owner, group, and everyone else. ACLs and POSIX permissions work together when ACLs are enabled. Mac OS X calculates the effective permissions by combining the two via this rule: effective access = (returned POSIX access) UNION (union of applicable ACL allow rules) TAKE AWAY (union of applicable ACL deny rules). In short, you can either have POSIX-only or POSIX and ACL. There's no "just ACL" model.
  • Whenever a new file or folder is created, the default permissions are set like this: (1) the POSIX owner is set to your account, (2) the POSIX group is inherited from the folder in which the new item is created, and (3) the POSIX permissions are set via the umask, which makes the file read/write for the POSIX owner and read only for the POSIX group and everyone fields. (This is POSIX 0755 for folders and 0644 for files.) If any inheritable ACL entries exist for the folder where the new item is created, the new item will inherit them (as inheritable entries - e.g. not explicit ones).
  • Whenever you copy a file or folder, the permissions on the copy are set according to the following rules: (1) the POSIX owner is set to your account, (2) the POSIX group is set to that of the copy's parent folder, and (3) the POSIX permission bits themselves are preserved. (4) Any explicit (not inherited) ACL entries are preserved from original to the copy, but inherited ACL entries from the original are discarded. The copy will inherit any inheritable ACL entries that are set on its parent folder.
  • Whenever you move a file or folder, everything is preserved. The POSIX owner and group do not change, and the POSIX permissions remain intact. All ACL entries - both inherited and explicit - are preserved.
Now the fun part:
  • In Tiger, the default permissions for the Public folder's Drop box were POSIX only. So Sally's Drop Box would have permissions like this:

    POSIX owner: sally, POSIX group: staff, POSIX permission bits: 0733 (owner can read and write, everyone else can only write)

    When Tim puts a file in Sally's Drop Box, here's what happens: Tim's file probably has POSIX permissions of 0644 (owner can read and write, everyone else can only read), due to the default permissions for new files (umask), even if he didn't create it. The copy in Sally's Drop Box would get these permissions:

    POSIX owner - tim (because Tim is the user who made the copy)
    POSIX group - staff (inherited from Sally's Drop Box)
    POSIX permissions are preserved - 0644.

    When Sally tries to access the file, she gets read-only permissions because only the POSIX owner - Tim - has read/write access.

    Of course, if the original file that Tim copied had different POSIX permissions - like 0664, then Sally could read and write the file, because the POSIX group - in this case staff - has read/write access. (Remember that we're using the convention that staff contains all users. See rule #2.) So you could ask Tim to manually change the POSIX permissions of his original file, or you could alter the umask so that new files get different default POSIX permissions. Either way, it's a pain to have Tim checking permissions, and a security risk to change the umask. (When you change the umask, you're altering the default permissions for all new items. Changing it to something like 0002 would produce new item permissions of 0775 or 0664, which gives the POSIX group read/write access. The risk is that you're giving the POSIX group these permissions without being able to define the group itself!)
  • There's a better way: use an ACL. Leopard systems will use these default permissions for a user's Drop Box, but ONLY IF the account was created after Leopard was installed. If the account existed on Tiger or earlier, the permissions for the account's home may not change to these.

    Just a minute. The fix for existing accounts is coming! Here's the way that new Leopard accounts work:

    The Drop Box folder uses the same POSIX permissions as it did under Tiger, but it includes an inheritable ACL entry that grants the user who is the POSIX owner read/write access for copied items! Here's Sally's example:

    POSIX owner: sally, POSIX group: staff, POSIX permission bits: 0733
    One ACL entry for sally that grants read/write permission to the Drop Box and to items that are copied into it.

    So, again, let's say that Tim copies a file to Sally's Drop Box. Here's what the copy's permission bits look like:

    POSIX owner - tim (because Tim is the user who made the copy)
    POSIX group - staff (inherited from the Drop Box)
    POSIX permission bits are still preserved - 0644 for "default" files
    An ACL entry for sally that allows read and write.

    Now Sally has read/write permissions to the file that Tim gave her, even though Tim is the POSIX owner. This is because both the POSIX owner (Tim) and Sally have read/write privileges to it. What's more, it doesn't matter what the POSIX permissions were for Tim's original file, because the inheritable ACL entry on Sally's Drop Box will apply to any items that are copied to it! And, Sally can move the file to any other location while preserving her access (remember that a move preserves all permissions).
  • So, what about the pre-Leopard accounts that don't work in Leopard? You can just create a new account and move your stuff to it, or you can reset the permissions of your home directory via Terminal, if you'd like. Here's how:

    Let's say that you are Sally, and that your short name is "sally". (So you would replace "sally" with your account's short name for these commands.)

    As an administrator, open Terminal and use these commands, in this order:
    $ sudo chown -R sally:staff /Users/sally
    $ sudo chmod -R 700 /Users/sally
    $ sudo chmod 755 /Users/sally
    $ sudo chmod -R 755 /Users/sally/Public /Users/sally/Sites
    $ sudo chmod -R 733 /Users/sally/Public/Drop\ Box
    $ sudo chmod +a "everyone deny delete" /Users/sally /Users/sally/Sites /Users/sally/Public /Users/sally/Desktop /Users/sally/Documents /Users/sally/Downloads /Users/sally/Pictures /Users/sally/Music /Users/sally/Movies /Users/sally/Library
    $ sudo chmod -R +a "sally allow readattr,readextattr,readsecurity,list,search,read,execute,file_inherit,directory_inherit,delete,writeextattr,writeattr,write,append,delete_child,add_file,add_subdirectory" /Users/sally/Public/Drop\ Box
Hope it helps!

--Gerrit

[robg adds: I edited this comment for formatting purposes only. No text was changed.]

[ Reply to This | # ]
Why this Happens
Authored by: sf addict on Oct 15, '08 05:31:02PM

Gerrit Dewitt is hereby pronounced the Permissions Prophet!
He translateth that which was once incomprehensible into... the comprehensible (well after two or three readings- comprehensible, anyway).
He transmuteth that which was once indigestible into merely tough to swallow bite-sized chunks (think retentive, people!).
He removeth the darkness shrouding the dreaded POSIX and affixeth it with light- (ok, we're still a little on the dim side, but enlightened-er nontheless).
For this! We proclaim Gerrit Dewitt Permissions Prophet!

thanks!



[ Reply to This | # ]
GUI for ACL
Authored by: nwfrg on Oct 19, '08 01:51:38PM
There is a GUI tool for manipulating ACL permissions: Sandbox This can be very handy.

[ Reply to This | # ]