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 [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
