Skip navigation

finder can't write to NFS mount points

5095 Views 10 Replies Latest reply: Feb 9, 2013 3:43 AM by ILIV RSS
Omniver Level 1 Level 1 (10 points)
Currently Being Moderated
Sep 16, 2011 9:23 PM

From prior posts, this seems to be a recurring theme from prior OSX versions, but mine is the first I've heard of it in Lion.

 

None of my NFS automounts are writable in Finder, but they work find in terminal.  They used to work fine in Finder, and just stopped one day a few weeks ago.  Interestingly, when logging into another account, Finder would work for the automounts in that account ... until today, now this second account's Finder  shows the same behavior. 

 

Changing, moving, renaming the mountpoints shows no difference.  If I mount the shares by hand (mount_nfs), finder can write to them, but anything automounted is essentially 'read only' to finder.  The mounts are working fine (full read/write) in terminal.

 

Any ideas?  Anybody else seeing this?

Mac OS X (10.7)
  • MacFrank Calculating status...
    Currently Being Moderated
    Nov 20, 2011 7:13 AM (in response to Omniver)

    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

  • MacFrank Level 1 Level 1 (0 points)
    Currently Being Moderated
    Jan 1, 2012 1:52 PM (in response to MacFrank)

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

  • brandon71 Calculating status...
    Currently Being Moderated
    Jan 31, 2012 4:37 PM (in response to Omniver)

    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.

  • marchede Level 1 Level 1 (0 points)
    Currently Being Moderated
    Apr 17, 2012 8:21 AM (in response to Omniver)

    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.

    iMac, Mac OS X (10.7.3)
  • marchede Level 1 Level 1 (0 points)
    Currently Being Moderated
    Apr 21, 2012 2:08 PM (in response to marchede)

    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.

    iMac, Mac OS X (10.7.3)
  • kfa4 Calculating status...
    Currently Being Moderated
    Apr 28, 2012 9:03 PM (in response to Omniver)

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

  • Berk42 Calculating status...
    Currently Being Moderated
    May 4, 2012 4:42 PM (in response to Omniver)

    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.

  • kfa4 Level 1 Level 1 (0 points)
    Currently Being Moderated
    May 5, 2012 5:27 PM (in response to Berk42)

    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.

  • MacFrank Level 1 Level 1 (0 points)
    Currently Being Moderated
    Dec 8, 2012 4:48 AM (in response to Berk42)

    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

  • ILIV Calculating status...
    Currently Being Moderated
    Feb 9, 2013 3:43 AM (in response to Berk42)

    @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).

Actions

More Like This

  • Retrieving data ...

Bookmarked By (1)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.