Previous 1 2 3 4 Next 48 Replies Latest reply: Feb 28, 2014 7:49 PM by MacKlas Go to original post
  • Marc Loy Level 1 Level 1 (0 points)
    Seeing the exact same issue: read-write from Terminal; read-only from Finder with no permanent way to fix the access. Just submitted a bug as others have done here to add my voice to the chorus asking for a speedy fix.
  • CubeSys Level 1 Level 1 (0 points)
    After some experiments we have found a thing:

    We used to mount share as fileserver:/Docs, but the short name of the server is not fileserver, it is zeus.
    Changing share name as zeus:/Docs and mounting it in /Network/Servers (as was before) resolved the problem, now it is read/write.

    Strange thing is that /Network/Public that is mounted from dioniso.cube.lan:/Public (FQDN of OSX server) is readonly, tried even using short hostname (dioniso:/Public) does not work.

    Hope that it helps someone else

    CUBE Sys
  • karipk Level 1 Level 1 (0 points)
    I noticed two options:
    Mount the nfs as per use basis after login or downgrade.
    The login script was:

    MPOINT=/Users/username/mountpoint
    MPATH=fileserver:/raid0/data/home$/
    umount $MPOINT
    mount -t nfs $MPATH $MPOINT

    save as my_mount.command and set as login item in accounts.

    But as I said I decided to downgrade, because I hate "tricks".
    It seems that you can downgrade quite easily using the Snow Leopard install disc, Just boot from it and install. The system gets downgraded to the version your CD is. Then i Downloaded the 10.6.6 combo and installed it + Safari 5.0.4 + other updates.
    I had 10.6.6 install disc for the Macbook 17" and 10.6.3 for the Mac Pro.

    Kari
  • mwenzel Level 1 Level 1 (0 points)
    I noticed the same problem. Some months ago, I changed mounting my Solaris NFS shares from Finder mount with Cmd-K to Disk Utility, as I found out that the async option boosted up write speed from 3 MB/s to 70 MB/s. However, handling the permanent mounts was a little bit inconvenient, as I had to use links instead of partition entries in Finder.

    Now I dismounted the shares with Disk Utility again and mounted with Cmd-K without any options. Heureka! I can write again to the NFS shares, and they provide full write speed of Gigabit ethernet!

    Cheers
    Markus
  • -Michael- Level 1 Level 1 (0 points)
    I opted to try some experiments after seeing the successful results of mwenzel with doing an NFS mount via CMD-K in Finder versus the configuration of Disk Utility. After removing my NFS mount configuration from Disk Utility, I tried mouting via CMD-K in Finder--this worked for me also. I had full read/write access via Terminal AND Finder.

    So I did some more research. If I have my NFS mounts in /etc/fstab, these also fail in Finder. But if I do a manual mount via mount_nfs, these work fine. So I worked out a startup script to go under /Library/StartupItems that used mount_nfs. With this in place, the mount is done automatically at boot time and Finder is able to read/write to it properly. This isn't really a solution, but more of a hack/work-around, and I'm only going to use this on one test machine. The rest of my machines will stay at 10.6.6 until this bug is fixed.

    So it would seem that if automountd is involved in the mount, either via a configuration in /etc/fstab or Disk Utility, then Finder cannot write to the NFS mount. But if the mount is done via Finder/CMD-K or via a mount/mount_nfs command--Finder can write to the NFS mount okay.

    When I use the FSMegaInfo program to look at the mount point, when mounted via automountd, I get this:
    ############################################################################
    wks110$ ./FSMegaInfo FSGetVolumeInfo /nfs/opt
    volumeName = 'opt'
    createDate = 0.0.0 (Thursday, December 31, 1903 6:00:00 PM United States (Chicago))
    modifyDate = 0.0.0 (Thursday, December 31, 1903 6:00:00 PM United States (Chicago))
    backupDate = 0.0.0 (Thursday, December 31, 1903 6:00:00 PM United States (Chicago))
    checkedDate = 0.0.0 (Thursday, December 31, 1903 6:00:00 PM United States (Chicago))
    fileCount = 0
    folderCount = 0
    totalBytes = 2000326778880 (1862 GB)
    freeBytes = 960661266432 (894 GB)
    blockSize = 512 (512 bytes)
    totalBlocks = 3906888240 (1862 GB)
    freeBlocks = 1876291536 (894 GB)
    nextAllocation = 0
    rsrcClumpSize = 512 (512 bytes)
    dataClumpSize = 512 (512 bytes)
    nextCatalogID = 2
    finderInfo = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    flags = 0x8000
    filesystemID = 0x6375 ('cu')
    signature = 0x4244 ('BD')
    driveNumber = 1
    driverRefNum = 0
    ############################################################################

    But if FSMegaInfo looks at the mount, when mounted via just mount_nfs, I get this:
    ############################################################################
    wks110$ ./FSMegaInfo FSGetVolumeInfo /nfs/opt
    volumeName = 'opt'
    createDate = 0.0.0 (Thursday, December 31, 1903 6:00:00 PM United States (Chicago))
    modifyDate = 0.3385308853.17648 (Sunday, April 10, 2011 2:34:13 PM CT)
    backupDate = 0.0.0 (Thursday, December 31, 1903 6:00:00 PM United States (Chicago))
    checkedDate = 0.0.0 (Thursday, December 31, 1903 6:00:00 PM United States (Chicago))
    fileCount = 0
    folderCount = 0
    totalBytes = 2000326778880 (1862 GB)
    freeBytes = 961231900672 (895 GB)
    blockSize = 512 (512 bytes)
    totalBlocks = 3906888240 (1862 GB)
    freeBlocks = 1877406056 (895 GB)
    nextAllocation = 0
    rsrcClumpSize = 512 (512 bytes)
    dataClumpSize = 512 (512 bytes)
    nextCatalogID = 2
    finderInfo = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    flags = 0x0000
    filesystemID = 0x6375 ('cu')
    signature = 0x4e4a ('NJ')
    driveNumber = 1
    driverRefNum = 0
    ############################################################################

    The "flags" and "signature" labels seem to be the significant differences.

    When Finder can write (i.e., automountd is not involved) FSMegaInfo shows these labels set like so:

    flags = 0x0000
    signature = 0x4e4a ('NJ')

    When Finder cannot write (i.e., if automountd is involved) FSMegaInfo shows these labels set like so:

    flags = 0x8000
    signature = 0x4244 ('BD')

    Message was edited by: -Michael-

    Message was edited by: -Michael-
  • Vynce3 Level 1 Level 1 (0 points)
    To try to work around this problem I tried mounting the shares with autofs using SMB instead of NFS. I added the auto_smb file below.


    $ cat /etc/auto_master
    #
    # Automounter master map
    #
    +auto_master # Use directory service
    /net -hosts -nobrowse,hidefromfinder,nosuid
    /home auto_home -nobrowse,hidefromfinder
    /Network/Servers -fstab
    /- -static
    /Volumes/Network auto_smb



    $ cat /etc/auto_smb
    share -fstype=smbfs ://username:password@server/share


    This has the same problem! It appears that any shares mounted via autofs are not writable through Finder
  • UloPe Level 1 Level 1 (0 points)
    @CubeSys: Would you mind also posting your bugreport to OpenRadar (http://openradar.appspot.com/) so that others can see it?
  • Vynce3 Level 1 Level 1 (0 points)
    I've posted my bug report on OpenRadar: http://openradar.appspot.com/radar?id=1161410
  • Vynce3 Level 1 Level 1 (0 points)
    Apple closed my bug report today as a duplicate of bug 9062261. That bug is not listed on OpenRadar.
  • Clint W. Level 1 Level 1 (10 points)

    I've had the same problem since mid-February. Very frustrating. Bug 9062261 was submitted by me some time ago. I'd post a bug report on OpenRadar, but it looks like Vynce3 has already done so. I hope this gets fixed soon. Constantly tweaking my NFS shares has been a real pain. I mean c'mon. NFS support is a basic UNIX feature that should have all the bugs worked out by now. I know this is more of an issue with Finder in relation to NFS shares, but still. Kind of reminds me when KDE 4 came out. I had problems with Dolphin acting flaky too.

     

    I have a rather large iTunes library. I had my library pointed to an NFS share. It would seem that when you try and manipulate folders / files, this problem is present within iTunes as well. It would seem that iTunes uses the same API as Finder. (Noob developer speaking so be kind)  So, I have not been able to update or change anything in iTunes. If I do, I change the location of my iTunes library to something local (/Users/user/Music/iTunes/iTunes Media) make the changes, copy the new files via the command line, and then revert back to the NFS share. Someone mentioned earlier that re-mounting the share after a reboot seems to do the trick. For me, that seems to work 50 / 50.

     

    At this point, I'm just hoping it gets fixed soon.

  • Vynce3 Level 1 Level 1 (0 points)

    It seems like the update to the discussion forums deleted all of my notifications . Anyway, here's my current workaround for this problem.

     

    I created a script in the AppleScript Editor with the following contents:

     

    tell application "Finder"
        mount volume "nfs://server/share1"
        mount volume "nfs://server/share2"
    end tell
    

     

    I then saved it as an application and added it to my Login Items in System Preferences. This mounts the shares via NFS to /Volumes at login. I then symlinked each share to my desired mount point (/Volumes/Network) from the /Volumes mount point:

     

    $ ln -s /Volumes/share1 /Volumes/Network/share1
    $ ln -s /Volumes/share2 /Volumes/Network/share2
    

     

    This essentially looks almost the same to the rest of the system as the AutoFS mounting method. Cons of this approach are that the shares are mounted on a per-user basis and not system-wide, and if the shares get unmounted for any reason they won't automatically mount when you try to access them (you have to manually run the script to mount them again).

  • Pascal G Level 1 Level 1 (0 points)

    try this script from Greg Ercolano.  It works fine for NFS mounts in our animation computer lab

     

    http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1847+1847

    [OSX/ADMIN] Boot script to mount multiple file servers

     

    cheers

    Pascal

  • tebruno99 Level 1 Level 1 (0 points)

    This seems to be a pretty big error.  I have it as well.  I find that if I remove DiskUtilities NFS completely, and manually mount the shares that Finder is able to access them again.  Downside, I have to mount them manually after every reboot:

     

    Example:

       mkdir /Volumes/NFS_Storage

      sudo mount -t nfs 192.168.1.13:/storage  /Volumes/NFS_Storage

  • Bernie Case Level 1 Level 1 (35 points)

    There's another way to do this, which I've been using for quite some time.  1st, mount the NFS export from the Finder.  2nd, drag the desktop icon of the mount to the Login Items section of the Accounts System Preferences Pane.  This will use the Finder for remount upon reboot and avoid this bug in 10.6.7.

  • kavehv Level 1 Level 1 (15 points)

    How are you mounting the NFS export "from Finder"?  This doesn't work for me at all.