• firewall behavior
• exporting file system syntax and use of pseudo file systems
• difference in mount command syntax

I am running systems that use SELinux and firewalls*. I have one Centos 5.3 NFS server and three client machines running as virtual machines** on the server. My goal was to establish remote file systems for the virtual machine clients. I’ll skip some of the introductory steps to set up the nfs server process that are listed in the doc.

I’ll list the commands that I used to export the file system from the server and the mount command I first used on the client. The file system that I was attempting to export was /junk/client1. On the server (server.stevens.net), I added the following to /etc/exports:

and I used the following mount command on client1.stevens.net (and received the error shown):

A bit surprised that it didn’t work, I poked around the Internet and I found some good info that ultimately helped me get on the right track at Miles Brennan’s Linux Home Server HOWTO page. He does an excellent job explaining the pseudo file system configuration required for version 4 of NFS.

I built out the following psuedo file system on the server:

I then created bindings in /etc/fstab between /NFS4exports and /junk directories as follows (Bindings are like symbolic links, but the files are available in both filesystems, rather than being linked to the source location.):

Then I list the pseudo file systems in the /etc/exports file, and it is critical to note that the fsid=0 option be defined on the /NFS4exports file system (even though /NFS4exports itself will not be mounted by a remote client). Then all exported file systems are sub-directories of this system. If I had additional file systems elsewhere on the server that I wanted to share (say, /home), I would need to create an entry in the pseudo file system and bind it to /home in fstab.

Then I mounted the file systems from the client1 system. A major difference between the NFSv3 and NFSv4 command is that the root pseudo filesystem is not included in the identity of the remote file system (i.e., the NFS4exports directory is omitted from the command.

And on client2, showing an example that it can mount the client1 directory, but can’t see anything or write to it:

And that completed my setup (except to modify /etc/fstab so that the new /remotesys file system will automount at boot). The main point was to learn about NFS, but I also ended up with a way to provide storage for my virtual machines outside of the .vmdk virtual file system.


Footnotes:
* NFSv4 plays better with firewall because, unlike NFSv3, it does not make use of portmapper and rpc.mountd, rpc.statd, and rpc.lockd. I just had to open port 2049 on the firewall for NFS. However, during some troubleshooting, I needed to execute “showmount -e sserver.stevens.net’ from a client machine. The firewall blocked it, because it uses rpc.mountd and portmapper picks a random port by default. I used /etc/sysconfig/nfs to define a static port for rpc.mountd and then opened this port on the firewall too.
** As a side note with respect to the virtualization setup, I created one vm and installed a small, simple Centos image. Then I copied the files twice to new folders in /var/lib/vmware/VirtualMachines. Then I imported these virtual machines into VMware Server to quickly make some clones. Just a quick edit of the /etc/sysconfig/network file to update each machine to a unique hostname, and I had 3 distinct client machines.

So, I have a Linux machine with tons of HDD storage space (250 + 500 GB) .  The XP machine needs additional space.  And it must be transparent to the rest of the family.  I used Samba to create file shares on the Linux machine, then created mapped network drives on the XP machine that connect automatically to the Linux machine’s HDDs at login.  It wasn’t hard, but did trip me up on a couple points.

Samba is an open source software package that allows Linux/Unix machines to participate in Windows networking as nodes in the Windows “Network Neighborhood” and therefore provide file sharing between Linux and Windows machines.  It was easy to install the Samba package on CentOS, using the Add/Remove software package from the desktop GUI, and included a GUI configuration tool for Samba.  The CentOS deployment guide provides good guidance for configuration, and the samba.org site provide an excellent extra level of detail for the software.  A couple of points to add that were key learnings for me:

1. The Samba GUI provides a simple, easy configuration tool for the basic samba config, identifying the workgroup name, shared volumes and users/passwords.  The manual config is accomplished via the smb.conf file in /etc/samba.  Manual edit of the conf file provides more options than the GUI, including logging level, source IP address filtering, and preventing access to home directory.  However, if you make changes to this conf file, then make changes to the config via the GUI, your manual changes to the conf file will be removed.  So make the simple GUI config changes first, get a functioning system, then tweak the configuration with vi edits of the smb.conf file.
2. Windows XP required that I set samba up with “user” authentication, not “share”, and I had to encrypt the passwords on the Samba config.  Windows would not attempt to make connections when Samba was configured with unencrypted passwords.

The Samba config was easier to config than the Windows XP side.  Once I had the Samba server running, I was able to go into “Network Neighborhood”, view the “workgroup nodes” and connect with the user/password set up in Samba.  Then I could map a drive letter to a share folder on the Linux box.  Easy, right?  Almost.  Even though I asked Windows to ‘reconnect at login’, Windows could not.  Looking at the Samba logs in var/log/samba/smbd.log (with logging set to level 3 via the conf file “log level = 3) I could tell that the problem was with XP, not Samba, and I suspect that Windows was not chaching the password.

The solution was a batch file that runs at startup on the XP machine.  I found a forum post that explained the syntax very well, using the net use command.  My specific command was “net use S: \\server\storage passwd /USER:username”  Then I just had to store the batch file in the ‘startup’ programs folder for “All Users”, and now the drive maps automatically at startup.  Then I’ll convert the “My Pictures” folder to a shortcut to a folder on the Samba shared volume.  Perfectly transparent to my family.

As long as the power is on the Linux box.

Update Jul 20, 2009:

I rebuilt my machine and used a firewall and Security Enhanced Linux (SELinux), which created a couple additional challenges.  First, the firewall had to be configured to allow smb protocol for Samba, which was easy.  Second, (and a bit more tricky) the smb.conf file had notes for SELinux, indicating that the shared folders needed to be marked with “samba_share_t”. The current labels can be displayed with “ls -ldZ /path”, and the label on a share folder can be set with “chcon -t samba_share_t /path”. Once I resolved these issues, all was fine.

Photo credit, eheçatzin