[PLUG] Exporting via nfs

[Mike Connors]

Mel Andres wrote:
> We recently purchased a MacPro notebook. I have most of my music and 
> video files on my linux debian machine in subfolders under mounts 
> /share1 and /share2. I have both of these in /etc/exports, and nfsd is 
> running. However, I am unable to mount_nfs them from the Mac. I very 
> likely could have something incorrect with my exports file. I think I 
> also have to tweak my Belkin router. 
Do you get an error mssg on the Mac when you attempt to mount the nfs 
share?

How about any nfs mssgs in syslog on the Debian box?

I found this write-up on easy GUI-based NFS share access from a Mac OSX 
client using Avahi / Zeroconf / Bonjour.

Most of the online materials I've found that discuss setting up an OSX 
client for NFS shares go through the cumbersome process of configuring 
via NetManager. The downside I discovered to this, particularly for 
iBooks, is that the Finder will rather ungracefully hang when I'm out 
somewhere else and it tries to access the shares defined for my local 
home LAN. Plus, the NetManager settings are essentially hard-coded in a 
way, so any time I make changes to my server setup, I have to replicate 
them in my iBook's NetManager configuration. How tedious.

I stumbled across a much more elegant setup a while back (incidentally, 
when researching how SMB broadcasts its presence) -- use Avahi / 
Zeroconf / Bonjour. Avahi is the Linux daemon; Zeroconf is the spec; and 
Bonjour is what Apple calls its implementation (formerly "Rendezvous"). 
Setting up Avahi on your Ubuntu NFS server to broadcast announce your 
NFS shares can greatly simplify GUI access from your Macs, and also 
potentially simplify how your /etc/exports file is organized. There are 
a couple useful links here in one of my previous posts which you should 
read.

Once you get Avahi installed and running on your Ubuntu server machine, 
open a terminal and cd over to /etc/avahi/services. There shouldn't be 
much of anything here to begin with, so start off by typing in sudo vim 
nfs.service (pick your editor of choice; I just like vim ). Any config 
files for announcing services via Avahi *must* be in this directory (or 
linked to from it) and *must* have the extension service. Now type in 
something like this:

Code:
<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name>Zephyrus Shared Music</name>
<service>
<type>_nfs._tcp</type>
<port>2049</port>
<txt-record>path=/data/shared/Music</txt-record>
</service>
</service-group>
The black text should be identical on your end; change the blue as 
needed to suit your own setup. Also note the underscores in the <type> 
tag -- these are required. The port is the NFS port used when you've got 
the [font=courier]insecure[font] option specified in your /etc/exports 
file, so that might need changing. And obviously you'll need to specify 
your own path to your NFS share. One caveat here is that, as best as I 
can figure, you can only specify one share per service file. The Avahi 
daemon for Linux is still a young project, and documentation is limited, 
but I expect better docs and software to help configure daemon options 
will appear in due time.

Once you've got your service files in place, restart the Avahi daemon by 
typing in sudo /etc/init.d/avahi-daemon restart. Then go to your Mac 
machine, open a Finder window, and click the Network globe thingy in the 
upper left. You should now have a "My Network" folder here, which will 
contain whatever NFS shares you've specified. And the nice thing is that 
this is a purely dynamic setup -- automount takes care of mounting 
automagically via the special Network folder, and the the Finder won't 
hang now when you go somewhere else and happen to accidentally try to 
access a non-existent share, unlike the NetManager setups I've often 
seen described online when researching how to do this.

I mentioned earlier that this can simplify your /etc/exports file 
somewhat. The trick here is the <path> tag. As you see further above, my 
exports file just shoves out the whole /data directory. Meanwhile, my 
Avahi service config file here only broadcasts one subdirectory, so 
that's all the GUI user will see (you can also see these via Konqueror 
by typing zeroconf:/ into the address bar). That's also all the GUI user 
can access.

But -- the whole /data share is still available for anyone to mount via 
the CLI, so be forewarned that this simplified /etc/exports file 
approach is not a good way to limit access to any sensitive data. You 
will need to spend some time setting up proper file permissions to 
ensure that no one who shouldn't can mess with your files. For instance, 
one of the subdirectories I advertise via Avahi is a user's documents 
folder, at /data/[username]'s Docs. Although anyone on my LAN can see 
this directory in any zeroconf-enabled browser (like Konq or the 
Finder), I've set up permissions so only certain users can actually open 
the directory to see the contents -- anyone else just gets an error that 
they don't have the required permissions. In this case, I did this by 
typing in sudo chmod 750 /path/to/directory. This way, the owner (the 
first digit) gets full read/write/execute permission, group members (the 
second digit) get read-only and execute (needed on a directory so you 
can open it), and anyone else (the last digit) can't do anything to it 
(except root, of course). Another useful trick for directories shared 
within a group is the setgid bit, which I've set on the above-shown 
Music folder by typing in sudo chmod 2770 /path/to/directory. The 2 on 
the front ensures that any files or directories created within this 
directory are created with the same group ID as the directory itself 
(after the 2 come the usual user, group, and other permissions). Note 
also that any binaries executed with the setgid bit set will run with 
the permissions of the file's group, so make sure to choose an 
unprivileged group when setting up your shared groups. Wikipedia has a 
very useful article on file system permissions, particularly the section 
Notation of traditional Unix permissions, which I'd recommend reading.