NFS and Mac read AND write permissions

[Guest]

I was excited yesterday when I got an nfs share up and running on an old desktop. The share mounts wonderfully on a little toy computer (Acer netbook) running Xubuntu 11.04 with both read and write permissions. The problem is on my Mac. I can mount the share and see all of the files but I do not have write permissions.

On the server side, my /etc/exports file says:

/home 192.168.3.4(rw,async,all_squash,insecure)

Like I said, the share mounts from Finder (Go>>Connect to) and appears on my desktop. However, I can't transfer files to the server and when I open a document it is read only. What do I need to do on the Mac side to make everyone play nice? I would eventually like to connect my wife's iMac so we can store all of our music on the server.

[GreyGeek]

Re: NFS and Mac read AND write permissions

Looks like a permission problem.

IF Mac is like Linux you may have to add yourself (her?) to the nfs group.

[oshunluvr]

Re: NFS and Mac read AND write permissions

I've never heard of a specific nfs group before GG.

I'm going to take a shot at this but I'm not a mac user so I may not have the answer...

How you solve this will depend a lot on your security needs. If one assumes you have a firewall that's handling all your security needs, it's easy enough to open up the files to everyone.

NFS share permissions are set by the network permissions, the export command, and the directory/file structure it self. Since you have full access on the Acer and browse access on the mac, we can assume that the network is setup properly.

I'm going to guess you're the first user you entered on both the acer and the server? You're likely using the same userid/groupid (numerical - textual names aren't important) on both computers and thus you got full access. Default behavior for (K)Ubuntu is all users get a private group id.

You can solve this in several ways:

• Giving rwx permission to all users on the server exported directories.
• Mapping all users who access the NFS shares to the same UID/GID.
• Creating a specific group for sharing and using the group sticky bit.

In my case, my family media server is accessed by anyone logged onto my local network. I want my wife and myself to be able to save and delete files but not my 7 year old or guests. So my wife and I are members of a group called "shared" and the exported directories are owned by that group (I don't use the same UID/GID on my server as my personal desktops). Setting the group sticky bit causes newly added file to change to the directories group thus allowing me to delete something added by my wife and vice-versa. Other users have r_x access so they can view a video or picture, but not remove or add then. I have a "deposit" directory that is world writable so a guest may leave something for me. Another neat feature of this setup is by removing other user r_x permissions, I can block a particular directory from guests (and my daughter) but not from my wife and myself.

I also export another directory to allow anyone to backup their home directories. It has full access to everyone, but no sticky bits are set. This way, I can backup my home into it but other users can't get into my home backup.

In your case, you may find it simpler to just open the media directories to everyone and not worry about it.

[GreyGeek]

Re: NFS and Mac read AND write permissions

"nfs group" -- neither had I, but the last time I used the nfs file system was about 6 or 7 years ago. And, these days, everything seems to get its permissions from an existing group or creates a group when it is installed. The user permission problem is a gotchas that gives a lot of people problems

Problems with permissions, uid's and gid's: Mounts OK, but access to the data is impossible or not as specified
...
4: If it mounts but can't access, check permissions, gid's and uid's
Generally speaking, the permissions on the server don't affect the mounting or unmounting of the NFS share. But they very much affect whether such a share can be seen, executed, read or written. Often the cause is obvious. If the directory is owned by root, permissioned 700, it obviously can't be read and written by user myself. This type of problem is easy to diagnose and fix.

Tougher are root squashing problems. You access an NFS share as user root, and yet you can't see the mounted share or its contents. You need to remember this is probably happening because on the server you're operating not as root, but as the anonomous user. A quick test can be done by changing the server's export to export to a no_root_squash and single IP address (for security). If the problem goes away, it's a root squashing problem. Either access it as non-root, or change the ownership of the directory and contents to the anonomous gid or uid.

By far the toughest problems are caused by non-matching uid's and gid's. Let's say you share your home directory on the server, and you log in as yourself on the client and mount that share. It mounts ok (we'll assume you used su -c or sudo to mount it), but you can't read the data -- permission denied!

That's crazy. The directory you're sharing is owned by myself, and you're logged into the client as myself, and yet you don't have permission to read. What's up?

It turns out that under the hood, NFS requests contain numeric uid's and gid's, but not actual usernames or groupnames. What that means is that if user myself is uid 555 on the server, but uid 600 on the client, you're trying to access files owned by uid 555 when you're uid 600. That means your only rights to the mounted material are permissions granted to "other" -- not to "user" or "group".

The best solution to this problem is to create a system in which all boxes on your network have the same uid for each username and the same gid for each groupname. This can be accomplished either by attention to detail, by using NIS to assign users and groups, or by using some other authentication scheme yielding global users and groups.

If you cannot have a single uid for all instances of a username, suboptimal steps must be taken. In some instances you could make the directory and files world-readable, thereby enabling all users to read it. It could also be made world-writeable, but that's always a bad idea. It could be mounted all_squash with a specific anonuid and/or a specific anongid to cure the problem, but once again, at least from the NFS viewpoint, that's equivalent to making it world readable or writeable.

If you have problems accessing mounts, always check the gid's and uid's on both sides and make sure they match. If they don't, find a way of fixing it. Sometimes it's as simple as editing /etc/passwd and /etc/group to change the numeric ID's on one or both sides. Remember that if you do that, you need to perform the proper chown command on any files that were owned or grouped by the owner and/or group that you renumbered. A dead giveaway are files that are listed with numbers rather than names for group and user.

[oshunluvr]

Re: NFS and Mac read AND write permissions

Sounds like my "shared" group idea isn't that original...