Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Users on a college network can see the shared folder but cannot write to it. No problem seeing it but cannot write to it. Have added permissions to sharepoint on Server Admin.

share|improve this question

1 Answer 1

To make filesystem permissions work correctly between Mac OS X clients and servers, you need to ensure that the clients and servers are using the same "users and groups database", so to speak.

That basically means they need to be bound to the same Open Directory or Active Directory server, so that the client's notion of the current user's numeric User ID and numeric Group IDs match the server's notion of the UIDs and GIDs associated with the shared files and folders. AND, you need to log into the client Mac's GUI using the appropriate network account, so that the client machine's Finder's notion of your UID and GIDs matches the AFP client and server's notion of your UID and GIDs.

If you don't do that, you'll run into problems like this:

On the server you created an account "KevinKelley", UID 1024. Using that account on the server, you create a folder and share it.

On your client Mac, you created a local administrator account "KevinKelley" when you first set it up. This account has UID 501.

You log into the GUI on your client Mac using the local KevinKelly (UID 501) account. You then do "Connect to server..." from the Finder and mount the share point. When authenticating to the server via AFP (Apple Filing Protocol, the default file sharing protocol for Macs), you log into the "KevinKelley" (UID 1024) account on the server. You were thinking that both accounts represent you, and have the same long and short names, so you think you should be good to go. But they have differing numeric UIDs, so there's a mismatch, so your client-local account 501 won't be able to write to a file that's owned by account 1024 on the server. The Finder and the AFP protocol try to hide some of the problems caused by this mismatch, but the illusion is not always complete.

To check if this is your problem, do this:

In Terminal on the server (or when SSH'd into the server), do an ls -nled /path/to/shared/folder and see the server's idea of which UID and GID are associated with the file.

Now, on a client machine, log into the GUI using the account you usually use. Then launch Terminal and type id to see the UID and GIDs of the current account. Compare this UID to the UID associated with the shared folder on the server that you found in the previous step. If they don't match, you're probably hitting this problem.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.