No right to open file once copied on the desktop

Question

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.

Edit:
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 ?

Edit:
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.

Answer 1

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.

Answer 2

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://support.grouplogic.com/?p=1508

https://discussions.apple.com/thread/1423847

http://www.insanelymac.com/forum/topic/67625-preping-for-105-permissions-issues-with-afp-shares/

http://lists.apple.com/archives/macos-x-server/2010/Dec/msg00267.html

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

Answer 3

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/ruby-1.9.3-p385/gems/libv8-3.11.8.13-x86_64-darwin-10/vendor/v8/out/x64.release/libv8_base.a
    /Users/jayands/.rvm/gems/ruby-1.9.3-p385/gems/libv8-3.11.8.13-x86_64-darwin-10/vendor/v8/out/x64.release/obj.host/tools/gyp/libv8_base.a
    /Users/jayands/.rvm/gems/[email protected]/gems/libv8-3.11.8.3-x86_64-darwin-10/vendor/v8/out/x64.release/libv8_base.a
    /Users/jayands/.rvm/gems/[email protected]/gems/libv8-3.11.8.13-x86_64-darwin-10/vendor/v8/out/x64.release/libv8_base.a
    /Users/jayands/.rvm/gems/[email protected]/gems/libv8-3.11.8.13-x86_64-darwin-10/vendor/v8/out/x64.release/obj.host/tools/gyp/libv8_base.a
    /Users/jayands/Documents/2013-02-10.wav
    /Users/jayands/Documents/2013-02-17.wav
    /Users/jayands/Documents/2013-02-24.wav
    /Users/jayands/Documents/2013-03-03.wav
    /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/Library/Caches/com.apple.Safari/Cache.db
    /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

find

1. man find from the Terminal
2. This tutorial

chmod

1. man chmod

sudo

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.