I'm new to Mac, so I may not have the correct vocabulary.

  • We have a Mac 10.5.x configured to share files with AFP and SMB.
  • We have 4 other Mac as clients, various versions between 10.5 and 10.6.
  • Each of them access the server with the correct user+password.
  • The share is now configured to ignore permissions, but the problem was identical before that.
  • We can create/open/modify/delete/rename/etc files on the server, from every clients.

The problem :
When we copy a file from the server to the desktop of a client, the copied file can not be opened. The error message says the permissions don't allow the file to be read.
This is for every file from the server, on all 4 clients.
The files are copied with the finder, from the client.

I checked the permissions. On the server's share, when I look at the permissions from a client computer, every files are -------rw- cedric cedric (read-write for everyone) with the user and group identical to the people connected (here cedric, but this is another user when viewed from another computer).
Once the file is copied on the desktop, the permissions and owner are the same. So it is not possible to open the file because the permissions are not correct (I just tested on Linux, when a file is RW for everyone only, the owner can't open it).

So, is there a way to automatically copy the files with better permissions ? Or the share the files correctly ?

Every client computer is now upgraded to 10.6.x for the oldest, and 10.7.x for the two others. The problem is exactly the same.
I also noted one computer can't save files from Adobe softwares to the server. The user saves the files on his desktop, then use the finder to move them to the server.

  • How do you do the copy? Using the finder? Do you initiate the copy from the client?
    – Huygens
    Feb 24, 2013 at 15:22
  • @Huygens: question updated with details Feb 24, 2013 at 18:33
  • 2
    This is a known issue in OS X 10.5, see my answer below.
    – gosmond
    Feb 26, 2013 at 18:16
  • 1
    Raw guess: this problem can maybe be corrected by setting up some sort of umask for the AFP share (I don't know how to do this). Feb 26, 2013 at 19:26
  • 1
    @BertrandSCHITS - Not likely. I & thousands of other users encountered this problem extensively back when OS X 10.5 was current - it was a serious bug in the operating system. 10.5 failed to properly respect POSIX permissions, had something to do with the roll-out of ACL's in OS X IIRC.
    – gosmond
    Feb 26, 2013 at 20:39

3 Answers 3


It sounds like you are using a non-server Mac to act as a server. Is this correct? If so I highly advise you to upgrade to some version of OS X Server.

If I am correct, your issue is caused by using standard Mac (or POSIX) permissions to handle your file share. This is the only option you have for a standard Mac when sharing files. This causes permissions issues, whether you are using AFP or SMB protocols (though SMB is worse in this respect).

If you can upgrade to OS X Server, you will want to first clean up permissions on the folder you wish to share (thus fixing any existing issues). Then create users & groups to model your organization structure. From there you will create a new file share using the Server app. Don't change any of the default permissions it gives. Instead click the "+" button to add a new Access Control Entry. This is a special type of permission that OS X Server can grant, and it resolves all of the permissions issues a standard Mac will give you in such a setup.

Peachpit Press offers a great write-up of all of this in their OS X Server manuals as well, though I couldn't find anything to link to directly. I hope this helps.

  • The question says he's using an OS X 10.5 machine to serve AFP & SMB shares. So, it's a mac server.
    – gosmond
    Mar 2, 2013 at 8:53
  • 2
    You cannot safely make that assumption. Any OS X 10.5 system can serve AFP & SMB shares. Go into System Preferences > File Sharing. Create a shared folder. Check the option to share to Windows users as well. You have then created an AFP & SMB share. But using POSIX-only permissions. Even if he is using OS X Server proper, he will want to make sure he has provisioned access using ACEs instead of POSIX permissions. As a Mac systems administrator myself this sounds like classic POSIX limitations to me.
    – bispymusic
    Mar 2, 2013 at 15:35
  • 2
    Secondly, he is now using 10.6 and 10.7 and the issue persists.
    – bispymusic
    Mar 2, 2013 at 15:36
  • 1
    My mistake. I misread your answer as "using a non-Mac server" rather than what it actually says, "using a non-Server Mac."
    – gosmond
    Mar 2, 2013 at 15:52

There are known issues (Apple-created bugs) with several revisions of OS X 10.5 Leopard Client and AFP file access, including permission problems and in certain cases even the potential to lose or overwrite files completely.

There is no work-around for these bugs, they are in the operating system itself and can be reproduced on 2 freshly-formatted & installed Macs running Leopard 10.5, and most or all of the later revisions, i.e. 10.5.1, 10.5.2, etc.

Your best solution is to be sure to update all 10.5 Macs to 10.6.8 Snow Leopard. Failing that, updating everything to 10.5.8 (the last release of Leopard) may solve your problems.

Here's a list of references that go into more detail:





http://www.mailinglistarchive.com/html/[email protected]/2008-07/msg00409.html


The easiest way to do this is to use the Terminal. To do so, you need to have sudo access, which I'm assuming you're familiar with, conceptually, at least, since you mentioned Linux.

TL;DR: find . \! -perm 666 -type f -exec sudo chmod 666 {} \; is a one-liner that will do the trick, assuming you run it from the exact folder that you want, e.g., $HOME/Desktop/files_are_in_this_folder. If it's just one file, however, you can just run sudo chmod 666 /path/to/the/file.

Allow me to explain, to the best of my ability, what's going on.

find(1) is an extremely powerful finding utility, much moreso than whereis. The reason it's so powerful is it takes so many different options; as a simpler example, try find $HOME -size +100M; this will find all the files, recursively, over 100 MB and show you a list of them. Mine output the following:

    /Users/jayands/.rvm/gems/[email protected]/gems/libv8-
    /Users/jayands/.rvm/gems/[email protected]/gems/libv8-
    /Users/jayands/.rvm/gems/[email protected]/gems/libv8-
    /Users/jayands/Library/Application Support/Steam/SteamApps/common/regnum/data0.sdb
    /Users/jayands/Library/Application Support/Steam/SteamApps/common/regnum/data1.sdb
    /Users/jayands/Library/Application Support/Steam/SteamApps/common/regnum/data2.sdb
    /Users/jayands/Library/Application Support/Steam/SteamApps/common/regnum/data4.sdb
    /Users/jayands/Music/iTunes/iTunes Media/Podcasts/Bronyville/93 Bronyville Episode 093 – Friendship Gives You Wings!.mp3

As you see, it'll find everything, even stuff you don't want to modify. If they have a specific naming convention, say, *.wav, you can specify the find command to search by name, as well. find . -name '*.wav'

I said all that to familiarise you with the easier part of find; the following is the part that tends to trip people up. find has directives you can have it do to what it finds. -print is so common it's the default one and generally doesn't have to be specified. -print0, however, is a bit more interesting: it does mostly the same thing as -print, but the 0 is a NUL character replacing the linefeeds; it makes piping to xargs easier. The one we're interested in, however, is the -exec directive, which allows you to run most simple shell commands on each file, which brings us to {} and \;. The \; is to escape a semicolon for termination of the exec command and the curly braces come from awk, if I recall correctly. They get replaced by what is found.

chmod is still around from the Unix days; in fact, a lot of the commands you can run in Linux in xterm have some analog in the Mac terminal. chmod 666 will give you read-write access for everybody; however, if you can't remember that, try chmod a=rw. Both of these commands mean: "take the file I'm about to tell you of and set the permissions to Read-Write access for everybody."

Also, since you're collaborating, you might want to look into running a private git, Perforce (p4) or Mercurial (hg) server, as these management systems also manage the permissions of the files.

More Info


  1. man find from the Terminal
  2. This tutorial


  1. man chmod


  1. man sudo

git: From the git homepage

If you need any more help, just ask.

Oh, before I forget: sudo asks for your admin password for that machine.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .