Unable to Copy Files to Other Users Dropbox

[mnewman]

Two frustrating experiences today trying to copy files to the ~/Public/Drop Box folder (mounted as a guest user via afp) on the machines of other users on our home LAN. Every time I get the following error message:

An error occurred.

The operation couldn’t be completed. (OSStatus error -48.)

src: /Users/mnewman/Downloads/MessagesBeta.dmg
dest: /Volumes/PATCHARIN’s Public Folder/Drop Box/MessagesBeta.dmg
item: /Users/mnewman/Downloads/MessagesBeta.dmg

I tried to Google that error code, but all I found was another user having the exact same problem.

[ganbustein]

What are the permissions on the Drop Box folder? If you want a guest user to be able to drop files into it, you'll have to make it at least world writable. (That is, "everyone" should be able to write.)

Files that your guest drops into the folder will be owned by the guest, not by you, even though it's your folder. After the drop, you may wind up with a file you can't do anything with.

The standard solution is to put an ACL on the Drop Box folder that automatically grants you full privileges to anything dropped into it. Starting from Leopard, OS X automatically sets up the drop box of a new account with the following permissions:

drwx-wx-wx+ 4 ronk  _ronk  - 136 May 22  2010 /Users/ronk/Public/Drop Box/
 0: user:ronk allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit"

Unfortunately, users do sometimes manage to mess up permissions on their home folders, usually through a careless application of Finder's "Apply to enclosed items" feature. The advice they get often includes, among other things, the shell command chmod -RN ~ to erase all those pesky ACLs Finder added in response. It also deletes the OS X-supplied ACLs, most of which are of the "deny delete" ilk, which many incautious users also consider pesky and good riddance. The ACL on ~/Public/"Drop Box" is different, though, in that it adds key functionality and not merely safety. If you've deleted it, you need to put it back manually:

cd ~/Public/"Drop Box"
chmod 733 .
chmod -N .
chmod +a "user:$(id -un) allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit

[mnewman]

Quote: Originally Posted by ganbustein What are the permissions on the Drop Box folder?

ozone:public mam$ ls -lea
total 16
drwxrwxr-x+  6 mam  staff   204 May 24  2011 .
0: group:everyone deny delete
drwxr-xr-x+ 21 mam  staff   714 Oct  2 15:07 ..
0: group:everyone deny delete
-rw-r--r--@  1 mam  staff  6148 Sep 16 22:13 .DS_Store
-rw-r--r--   1 mam  staff     0 Nov 29  2010 .com.apple.timemachine.supported
-rw-r--r--   1 mam  staff     0 Nov 29  2010 .localized
drwx-wx-wx+ 26 mam  staff   884 Feb 25 15:54 Drop Box
0: user:mam allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit

This is my wife's MacBook Air. It's relatively new. I've never fooled with it. My wife doesn't do command line at all. I'm sure she's changed nothing. I know I have changed nothing.

All I wanted to do was transfer the Messages .dmg file from my machine to hers so she could install the Messages beta.

Do you see anything in the above that would result in the error message I got?

I also got the same error when trying to copy files to the Drop Box on my step-daughter's MacBook. AFAIK, no one has ever fooled with the permissions on that machine, either.

[ganbustein]

grep -e -48 /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MacErrors.h
  dupFNErr                      = -48,  /*duplicate filename (rename)*/

[mnewman]

Interesting, but I got that error message the first time I tried. And, since I had just downloaded that file I'm sure there was no identically named file already in her Drop Box.

[mnewman]

Turns out this is a PathFinder bug. It always returns the duplicate filename error when copying a file to the Drop Box on a remote AFP volume. I'll report to the developer.

Finder copies to the Drop Box work fine.

Sorry I didn't mention PathFinder in the OP. But, thanks for you clues. I never would have gotten there by myself.