[PLUG] Exporting via nfs

[Mel Andres]

Mike Connors wrote:
> 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.
>
>
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
>   
Thank you Mike. I am sure this will be helpful. It will take me some 
time to process all of it. I will report here as things develop.

  Mel