NFS permission denied after 10.6.7 update

Question

Level 1

0 points

NFS permission denied after 10.6.7 update

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.

Anyone?

iMac 27" i7 - Late 2009, Mac OS X (10.6.7), NFS

Posted on Mar 22, 2011 11:14 AM

Reply

Answer 1

CubeSys

Level 1

0 points

Mar 30, 2011 9:24 AM in response to Marc Loy

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

Reply

Answer 2

karipk

Level 1

0 points

Apr 6, 2011 10:49 AM in response to tjware

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

Reply

Answer 3

mwenzel

Level 1

0 points

Apr 10, 2011 5:29 AM in response to tjware

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

Reply

Answer 4

Apr 10, 2011 1:06 PM in response to mwenzel

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 ('**')
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 ('**')
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-

Reply

Answer 5

Vynce3

Level 1

0 points

Apr 10, 2011 8:27 PM in response to tjware

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 😟

Reply

Answer 6

UloPe

Level 1

9 points

Apr 11, 2011 5:00 AM in response to CubeSys

@CubeSys: Would you mind also posting your bugreport to OpenRadar (http://openradar.appspot.com/) so that others can see it?

Reply

Answer 7

Vynce3

Level 1

0 points

Apr 11, 2011 6:15 PM in response to UloPe

I've posted my bug report on OpenRadar: http://openradar.appspot.com/radar?id=1161410

Reply

Answer 8

Vynce3

Level 1

0 points

Apr 13, 2011 6:36 PM in response to tjware

Apple closed my bug report today as a duplicate of bug 9062261. That bug is not listed on OpenRadar.

Reply

Answer 9

Clint W.

Level 1

10 points

Apr 16, 2011 9:03 PM in response to tjware

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.

Reply

Answer 10

Vynce3

Level 1

0 points

Apr 25, 2011 8:05 PM in response to Clint W.

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

Reply

Answer 11

Pascal G

Level 1

0 points

May 11, 2011 7:07 PM in response to Vynce3

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

Reply

Answer 12

May 21, 2011 5:50 PM in response to tjware

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

Reply

Answer 13

May 21, 2011 6:36 PM in response to tebruno99

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.

Reply

Answer 14

kavehv

Level 1

19 points

May 22, 2011 8:13 PM in response to Bernie Case

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

Reply

Answer 15

May 22, 2011 8:40 PM in response to kavehv

CMD+K (or, Go > Connect to Server) and then in the address box put nfs://server/export.

Reply