finder can't write to NFS mount points

Omniver,

I do in fact have the same problem. It is new to me since the Lion update. Snow Leopard ran fine.

I have an IcyBox NAS in my home network and used Disk Utility -> NFS Mounts to mount the shares of the NAS.

I have no issues accessing the shares in Terminal, but in Finder they will only show up read-only!

Sometimes I even get "Alias not available" in Finder when everything is perfect in Terminal.

I tried several special options in Disk Utility. Latest:

-P locallocks rsize=32768 wsize=32768 intr noatime soft

Any ideas?

Regards

Frank

So far, I found lots of posts about this problem, but nobody offered a solution.

Does anybody have an idea?

The only workaround I found was using mucommander instead of the Finder.

I hope, someday there will be a solution...

I'm seeing this too. It really does look like a bug in Finder to me. Any other protocol (AFS or SMB) is working just fine.

Same problem here, with Lion 10.7.3.

In Terminal, writing always hangs the command. But the write itself always completes, as I can see from the Linux server. It's just that the command (cp) hangs without returning back to shell prompt, and Ctrl-C won't kill it, although I can manually kill it from another shell.

It doesn't matter whether mounting from automount or manua mount. BTW, I use nfsv4 and use mount -t nfs -o vers=4

Once the hanging occurs, the hang happens to any process that attempts to access the nfs file system (like bash completion of a filename, umount, ls command, etc.)

I'll probably install macfusion and osxfuse and use remote mount using ssh instead, which is an overkill and not very automatic, but at least it worked on my other Mac.

Hmm, sounds like it fixed itself somehow when I fiddled around with the mount options -o vers=4,rwsize=1024,tcp then going back to no options. Weird. Fingers crossed. Spoke too soon. Still an issue.

Same problem -- can't write to automounts with Finder but Terminal works fine. Filed a bug: http://openradar.appspot.com/radar?id=1696401

Was digging around and getting this to work on my system today. The good news is that I did. I am running openSuse 11.4 for my nfs server.

What it was getting this to work was setting the correct flags on my nfs server.

Here is what my /etc/exports looks like:

/Media *(fsid=1,crossmnt,rw,insecure,all_squash,async,no_subtree_check,anonuid=1000)

the fsid=1 and crossmnt may be just a suse thing. I work with a lot of Suse (OpenSuse, SLES, and SLED) systems and I have had to put this in all of them, but I haven't when hosting from ubuntu and whatnot.

The rest of the flags are

rw=read/write, insecure allows for ports beyond 1024 to connect to the share

all_squash allows for all users to access and be treated as the owner of the share (I think this is right, either way I had set the flag this way for it to work for me)

async allows for better performance by allowing the server to respond to requests before any changes made by that request have been comitted to stable storage.

no_subtree_check improves performance. I have never had any issues with this affecting my systems before. More info on all of these can always be found on the man page for nfs.

anonuid=1000. 1000 is the user id of the user that owns the nfs share on my server. This makes it so that all requests appear to the server as if UUID 1000 is writing to the share, regardless of who is actually doing the writing.

To test this on my iMac I did the following:

1) Created a directory for my nfs share to be mounted at:

#mkdir -p /mnt/nfs/Media

2) mount the nfs share

#sudo mount -t nfs -o resvport 192.168.1.50:/Media /mnt/nfs/Media

Share mounted just fine. Everything worked from terminal. I then fired up 2 finder windows and dragged and copied a file from my mac to the nfs share. It let me drop it there. Hopped on my nfs server to make sure and the file opened just fine.

If you want to mount this share at boot everytime do the following:

1) Open Disk Utility

2) File --> NFS Mounts

3) Click the '+' in the bottom left corner

4) Enter the Remote NFS URL. In my case: nfs://192.168.1.50/Media

5) Enter the mount location. Once agian, in my case: /mnt/nfs/Media

6) Click on "Advanced Mount Parameters" and enter "resvport"

7) Verify that you are communication to the NFS server

8) Save

There you have it. I hope this helps resolve the question here.

Thank you Berk42. The title of this thread should probably be "finder can't write to automounted NFS mount points". Mounting with the mount/mount_nfs command and with cmd-K are known to work fine -- Finder can write to the mounted volumes. But creating a persistent automount with Disk Utility causes the problem, and it seems to manifest only after rebooting. If you are not experiencing that, and are running 10.7.x (OS X 10.6.8 clients work fine for me), then that makes me wonder if there is something different about my servers triggering the problem. I connect to servers running a wide variety of versions of the Solaris OS.

Berk,

if you still have that NFS server: could you try and set up the following:

create a directory structure on the server which is > 3 levels:

./Media/music/artist/album/

and put a few files in that directory.

Then use Terminal to cd into /mnt/nfs and do

chown user:somegroup

(where "user" is you and somegroup is a group you are member of)

chmod -R 2770 Media

Everthing should be

-rwxrws---

drwxrws---

now and you should be able to access everything in Terminal and Finder.

If I do that, and access

./Media/music/artist/album/

I will see songs very shortly and then nothing with Finder telling me 0 Bytes for 0 Files.

Terminal will show everything as expected.

Thanks!

Frank

@Berk42 This gave me a good hint as to where I should be looking for options that control write permission for NFS shares. Thanks.

In my setup I run Arch Linux and NFSv4. After reading 'man exports' it was clear that the key was all_squash, anonuid and anonguid options.

In plain English, when Finder copies to NFS share/export files and folders they have to be created on the NFS server. The server then has to decide who these files are going to belong to. Since the server has no way to tell what user (user ids: UID and GID) are currently used on the client machine, and also because it is, in fact, not always desired that files are created on a server with the same UID/GID as on the client, there basically two options. First, is to use all_squash which is going to 'anonymize' UID/GID and instruct NFS server to create files in such a way that they belong to nobody user. Alternatively, you can set all_squash, as well as anonuid=1000 and anongid=1000 to match first non-system user on a modern Linux system.

So, I know that I store files on the disk that is exported as a specific user, so I configured my NFS export/share to create files on behalf of the clients as that specific user (that's what anonuid and anongid are for).