Mounting an NFS share

Question

Level 3

825 points

Mounting an NFS share

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.

Mac Pro, Mac OS X (10.6.8)

Posted on Jan 30, 2012 10:11 PM

Reply

Answer 1

etresoft

Level 8

46,128 points

Jan 31, 2012 4:39 AM in response to Scotch_Brawth

How are you mounting the drive? As root or as a user? The traditional way to mount NFS is for the root to do it in /etc/fstab or /etc/auto_*. Then, on the server, use the map_static option to map your client GID/UID to those of the server.

Reply

Answer 2

Scotch_Brawth Author

Level 3

825 points

Jan 31, 2012 2:33 PM in response to etresoft

Hi,

I'm using the functionality provided by Disk Utility. Go to the File menu and choose NFS Mounts... Whilst I am au fait with /etc/fstab, I'd rather use Disk Utility in this case.

The map_static option is not something I came across when I was readin the man pages on my Ubuntu server. Let me have another look.

EDIT: I checked the man pages for nfs and exports on my server machine, and neither makes any mention of the map_static option. All I have are the "squash" options.

In the meantime, I'd be grateful if you could post a sample of what you use yourself, so that I can see where I'm going wrong 🙂 I'm new to NFS, so examples help a great deal.

Reply

Answer 3

etresoft

Level 8

46,128 points

Jan 31, 2012 5:09 PM in response to Scotch_Brawth

It is a pretty standard feature. This man page for exports describes it.

Reply

Answer 4

Scotch_Brawth Author

Level 3

825 points

Jan 31, 2012 6:15 PM in response to etresoft

Well, I'm sorry to say it's no longer a standard feature in Ubuntu 11.10 (which I did mention I was using). It was, in 8.04 "Hardy Heron" three-and-a-half years ago, but between there and 10.04 it's been removed. You can confirm by looking at the man pages for the newer releases at the page you linked.

Are you still able to offer advice, given the differences between your NFS knowledge and my NFS server's implementation?

Reply

Answer 5

etresoft

Level 8

46,128 points

Jan 31, 2012 7:46 PM in response to Scotch_Brawth

It looks like NFSv4. NFSv4 is supposed to prefer LDAP. The new static map option may be /etc/idmapd.conf.

Reply

Answer 6

Scotch_Brawth Author

Level 3

825 points

Jan 31, 2012 10:04 PM in response to etresoft

Hi,

Well, we're getting somewhere! I can now read the contents of the share, but not write to them.

On the server, I set the idmapd.conf to make the nobody group and user the same as the owner and group of the shared folder. My exports file looks like this:

/home/REDACTED/share

REDACTED/28(rw,sync,insecure,all_squash)

We're on the home straight—I can feel it. But you're going to have to advise me further. Specifically, which mount parameters should I use on the client-side (OS X)? Or, is there still something on the server-side that might need fixing?

Many thanks,

S.

Reply

Answer 7

etresoft

Level 8

46,128 points

Feb 1, 2012 5:37 AM in response to Scotch_Brawth

The problem is that you've been hacking around a lot. Once you discover the correct path, you need to undo the hacks. If you aren't familiar with NFS, you probably shouldn't be attempting unusual configurations. Get rid of the nobody and all_squash stuff. Establish a connecting as a real user. Use the mappings to give that client user the UID/GID they need on the server. Ideally, stop there. I you still want to hack it up, start from this working configuration.

Reply

Answer 8

Scotch_Brawth Author

Level 3

825 points

Feb 1, 2012 8:18 PM in response to etresoft

*sigh* I think part of the problem is the fact that NFS has moved on since you last fiddled with it, and you're at a loss given my particular situation. I suspect another problem is that the man pages on Ubuntu are occasionally incomplete owing to clearly-stated licensing complications.

Instead of being offensive, simply admit you're at a loss, and I'll move on... Perhaps someone else will have more complete knowledge.

S.

Reply

Answer 9

etresoft

Level 8

46,128 points

Feb 2, 2012 6:27 AM in response to Scotch_Brawth

Scotch_Brawth wrote:

*sigh* I think part of the problem is the fact that NFS has moved on since you last fiddled with it, and you're at a loss given my particular situation. I suspect another problem is that the man pages on Ubuntu are occasionally incomplete owing to clearly-stated licensing complications.

Moved on? I last "fiddled with" NFS sometime in 2000 I think. I gave it up completely when I bought my iBook because NFS was designed for a hard-wired topology and wasn't robust enough for wireless. Of course, I "used" NFS before that and still do. It was, and still is, quite flaky. I have worked in places with essentially unlimited IT resources and keeping NFS running has always been a challenge, even when you've contracted to Sun to provide said IT.

Instead of being offensive, simply admit you're at a loss, and I'll move on...

If I were trying to be offensive, you would know it 🙂

I'm not at a loss. In a simple, 2-machine configuration like this, NFS is trivial to setup. The strategy is the same as any type of configuration. Use the default settings. Get it working. If those settings are insufficient for your needs, backup your working configuration and hack it up. Of course, you are free to try any alternate method. In fact, I highly encourage it.

Perhaps someone else will have more complete knowledge.

Good luck with that 🙂

Reply

Answer 10

Scotch_Brawth Author

Level 3

825 points

Feb 2, 2012 7:29 AM in response to etresoft

Hi,

In a simple, 2-machine configuration like this, NFS is trivial to setup.

I would have thought that triviality was subjective. In this case, 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. 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. 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.

Use the default settings. Get it working.

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

I know nothing about NFS other than that its capabilities and integration meet my needs. I had a good look around for helpful walkthroughs and tutorials, but nothing that was explained sufficiently well enough to allow me to take advantage of it successfully. 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.

Perhaps someone else will have more complete knowledge.

Good luck with that 🙂

If you genuinely think you're able to help, then I'm happy to hear your advice. What would you recommend?

S.

PS:

If I were trying to be offensive, you would know it 🙂

I think most people, including myself, are frequently unaware when they are being offensive…

Reply

Answer 11

etresoft

Level 8

46,128 points

Feb 2, 2012 8:10 AM in response to Scotch_Brawth

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.

Reply

Answer 12

BobHarris

Level 9

53,075 points

Feb 2, 2012 8:37 AM in response to Scotch_Brawth

I wonder is your NFS server requires the client make a connection from a reserved socket port number? The following is from "man mount_nfs"

resvport
	Use a reserved socket port number. This is useful for mounting
	servers that require clients to use a reserved port number on the
	mistaken belief that this makes NFS more secure. (For the rare
	case where the client has a trusted root account but untrustwor-
	thy users and the network cables are in secure areas this does
	help, but for normal desktop clients this does not apply.)

Years ago (like back around the 10.2 days), I had to use this mount option to make an NFS mount to a specific server. It is the server that would make this requirement.

Reply

Answer 13

Scotch_Brawth Author

Level 3

825 points

Feb 2, 2012 9:41 PM in response to etresoft

Hi,

Etresoft:

It transpires that there is no idmapd.conf manual page on my Ubuntu server, though a web search revealed that one does exist for Linux in general. Having read that, I can see now that the mapping is an important aspect of NFS, but my man page for idmapd didn't really help me comprehend that. I'm going to look further into how to use idmapd.conf to improve my NFS setup.

One thing I'm looking into at the moment us how clients identify themselves to the server. Searching on the web indicated it was by uid/gid, but the man page I found for idmapd.conf indicates it's by "FQDN". I don't think it's referring to DNS resolution, though I could be wrong. I mean, I have BIND9 set up on my server to resolve my LAN's local IP addresses to domain names (and for caching), but I'm not sure that's what idmapd is looking for. Say my Mac Pro resolved (via my own Primary Master DNS for my LAN) to "macpro.home.lan" - would I use, say,

foo@macpro.home.lan = bar

to map user "foo" on my Mac Pro to "bar" on the server?

On a side-note: finding a centralised source of official documentation for NFSv4 is like finding a needle in a haystack - does such a thing exist? DuckDuckGo and Google finds only scraps of things here and there, and little of it official.

BobHarris:

I'll look into the resvport option - thanks.

S.

Reply

Answer 14

BobHarris

Level 9

53,075 points

Feb 3, 2012 4:59 AM in response to Scotch_Brawth

I don't think it's referring to DNS resolution

I have seen situations where a "Reverse" DNS lookup was used to validate that the other side was who they said they were. The return IP address in the NFS packet is used to do a Reverse DNS lookup to get the hostname, and if the name does not match the name expected the NFS operation is rejected.

Where I experienced this was in a Tru64 UNIX system and the customer was using /etc/hosts to setup their names and messed up one of the entries.

I do NOT know if Mac OS X or Linux NFS implementations use this feature, but with respect to DNS, that is how I remember NFS using it.

Reply

Answer 15

Scotch_Brawth Author

Level 3

825 points

Feb 3, 2012 7:36 AM in response to BobHarris

Hey,

Thanks BobHarris. I guess I really do need to find some decent, comprehensive documentation.

If you don't mind, I'm going to describe what my ultimate aim for these shares are, and maybe someone can suggest the best protocol to use - it may be that NFS is not right, and there's something more suitable out there.

I have two network devices (other than my Macs): a MyBook NAS; and a Dell Latitude 5400. I'd like to create two shares: a "Documentation" share; and a share that acts as an intermediary between my ethernet-connected Mac Pro and my 802.11n wi-fi-connected MacBook Pro.

I've decided to use my E5400 to host these shares because it's always powered-up (providing several services, such as Privoxy and Squid proxying), whereas the NAS has quite an aggressive power-saving mode and the 1TB drive takes a while to spin up and present the shares; because the NAS is relatively noisy when it's powered-up; and because my storage needs for these shares are very modest, and not worth bothering my NAS with.

The "Documentation" share is supposed to be a read-only repository of documentation related to all my software, hardware and household appliances (such as my A/V amp, Freeview STB etc). This share should only be readable by users on my Mac Pro and MacBook Pro, and only writable by root. If it could also be readable by an iPhone app, that'd be nice, but I don't expect it.

The "intermediary" share should be read/writable by all users on my Mac Pro and MacBook Pro, allowing me to use this share to store items that I'm working on using either device (though only one device at a time)---for example, TeX documents or GIMP files. This is because I tend to avoid using the Mac Pro where my MacBook Pro will suffice, for power-saving reasons.

I'm comfortable with my network's security (WPA2 Personal; soon to be WPA2 Enterprise once I figure that out too 🙂 ) so don't have a need for Kerberos.

So, going back to basics: what file-sharing package should I be using?

Many thanks for all the response so far,

S.

Reply