Mounting an NFS share

Question

Hi,
I'm attempting to mount an NFS share and having no success.  Regardless of the settings I try, the Finder still denies me access to the NFS share, even though it mounts fine.  I seem to have no read or write access to the share.
I've tried exporting the share (in /etc/exports on the server machine) in two ways: with
/home/REDACTED/share     REDACTED/28(rw,sync,all_squash)
And
/home/REDACTED/share     REDACTED/28(rw,sync,insecure,all_squash,anonuid=1001,anongid=1001)
In the second example, the anonuid and anongid are those of the shared folder's owner and group.  I added "insecure" because a how-to on the web claims that OS X won't work with any shares that don't have this specified.
With either of these settings applied, Disk Utility verifies the existence of the share, and mounts it.  However, I can neither read files within, or add files to, the shared folder.  The error produced is:
The folder “share” can’t be opened because you don’t have permission to see its contents.
I have tried the following Advanced Mount Parameters, each to no effect:
nodev resvport nolocks locallocks intr soft wsize=32768 rsize=3276
nodev nosuid resvport nolocks locallocks intr soft wsize=32768 rsize=3276 ro
nodev,nosuid,resvport,nolocks,locallocks,intr,soft,wsize=32768,rsize=3276
nodev,nosuid,resvport,nolocks,locallocks,intr,soft,wsize=32768,rsize=3276 ro
resvport,nolocks,locallocks,intr,soft,wsize=32768,rsize=3276
-i,-s,-w=32768,-r32768
-P
I'd rather not employ SAMBA, and the Apple File Sharing package for my server's OS (Ubuntu 11.10) appears to be bugged currently.  Besides, NFS would be a far neater solution.
Any helpful advice?
S.

Answer 1

Scotch_Brawth wrote:
I've simply come at NFS as being the most appropriate file-sharing implementation for my needs - it supports automatic mounting at boot using tech native to both my Linux OS and OS X. 
That is part of the problem. NFS is designed for environments where all servers are mounted (by root) at boot time and permissions are managed via NIS or LDAP. That is the default setting. If you are using something else, it requires some hacking.
I've had SAMBA working in the past, but I guess a certain air of contamination creeps in when using a Windows protocol to allow interaction between two UNIXy systems.
Plus, you would now have two different 3rd party reverse-engineered reimplementations of a foreign protocol.
AFP would be great, but despite receiving support on the Ubuntu forums and IRC, I failed to get it to work - it may be bugged; which would not be surprising, as 11.10 (with Kernel 3) has proved problematic in several other ways.
Perhaps Ubuntu is targeted more towards desktop rather than server usage. About the time I last played with NFS, I also played with Netatalk - with disastrous results. Supposedly Netatalk is better now. It's authors would be more than happy to sell you a support package.
I did use the default settings - they failed to allow a working NFS share.  I then applied the variety of settings as recommended by apparently knowledgeable people.  Still no success.  I have read that UID/GID settings are an important aspect of NFS, but the issue in this case (as far as I understand it) is that all UID/GIDs below 1000 are privileged in Ubuntu 11.10, whilst on OS X these are below 501.  So, the choice is either to give the shared folder owner a privileged UID/GID pair, or change the UID/GID of my Mac users to meet the NFS servers needs - not something I'm happy to do for so small a gain.
You can create a throwaway account on the Mac and just reset the GID/UID to values equal to an account on the Linux machine. That would establish that it is properly working in the default configuration. Then you could edit /etc/idmapd.conf.
For that reason, I use the "all_squash" option, because the share in question is not for anything remotely critical and the data to be transferred and stored is both worthless and transitory.
Since all_squash maps everything to nobody, you would have to hack up the permissions on the server to make everything world writeable. I think it will work with /etc/idmapd.conf and without all_squash.
I know nothing about NFS other than that its capabilities and integration meet my needs.
Just what are your needs? If the data is worthless and not critical then Netatalk might be the best option. If you can't get that to work, you could try MacFUSE on the Mac side and mount over sshfs. That is normally what I do. It isn't all that reliable, but you don't seem to require that.
What information I did find regarding OS X and NFS was that there were peculiarities that required certain settings to be present on the server and the client respectively - for example, OS X apparently requires "insecure" to be set as an option, or it simply won't connect properly.  I don't know why, but I have no choice to trust to the advice of others in this case, until I have sufficient grasp to take care of the whole thing myself.
This goes back to the expectation that NFS expects to be always connected and mounted by root. Apple sells very few desktop machines anymore so it assumes a different, user-centered environment. You could use "insecure" on the server side to allow connections from "insecure" ports > 1024 that a regular users can connect with via the Finder. You could use the terminal with "sudo mount_nfs -o resvport" to tell the Mac to use the root user to connect via a secure port instead.
If you genuinely think you're able to help, then I'm happy to hear your advice.  What would you recommend?
I appreciate your meeting me halfway. I think all you really need is /etc/idmapd.conf without all_squash. Then you could setup AutoFS and you could use NFS in a modern environment without even bothering to mount it.