Anyone else having issues with NFS mounts after the 10.6.7 update?
I have three mounts /Volumes/media/music, /Volumes/media/video, and /Volumes/media/photos. all coming from a Synology NAS. Before the update, I had no issues, but now I don't seem to have write permissions. I can't create new folders or copy files to existing folders. If I do a "Get Info" on any of the files/folders there it says: "You have custom access", and the Finder window has the pencil with the line trough it on the bottom of the frame.
The even weirder thing is, if I go to a terminal window, I have full permissions to do anything I want.
I've tried remounting and different options, but same result.
I saw in the release notes something about Trash and NFS home directories, but that's not really what I'm doing.
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.
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.
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!
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:
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.
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:
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).
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
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.
