Taco Steemers

A personal blog.

Setting up network shares with NFS and Linux systems

For quite a while, I have had a backup solution that I was not happy with. I have now remedied this. I am using a small server, a HP Proliant Microserver N40L. I tend to use Debian-based GNU/Linux systems at home. While I do eventually want my new solution to support Windows systems, it is not a priority. To support both Windows and Linux operating systems, I would use Samba. However, I have had mixed results with Samba, in home and small business settings. I am now succesfully using NFS (Network Filesystem Share) to back up computers with Linux on it. Unfortunately, NFS support under Windows isn't great. Apparently it is only supported by several Microsoft Windows Vista, Server 2008, Windows 7 Enterprise and Windows 7 Ultimate ( http://www.microsoft.com/en-us/download/details.aspx?id=2391 ). In this post I will outline how to install NFS under Debian-based operating systems, as a server and as a client. As it turns out, this is pretty simple.

The server We will be using a volume that is mounted under /media/backupspace .

First, we will install the required software (I'm using apt and sudo to get the necessary packages and rights, just substitute as necessary). sudo apt-get install nfs-kernel-server This install should make sure that everything required for NFS is loaded at startup.

Now we will mount this same volume in a directory that will be used by NFS. First, we create the new mountpoint sudo mkdir -p /exports/backupspace and then we bind the volume, the one that we wish to place the backups on, to that new mountpoint. We can do this manually with sudo mount --bind /media/backupspace /exports/backupspace To have it be mounted during startup, we can add it to the /etc/fstab file. This file can only be edited by a superuser. We would add the following line: /media/backupspace /exports/backupspace none bind 0 0

Three other files are relevant to our configuration: /etc/default/nfs-kernel-server /etc/default/nfs-common /etc/exports These three files can also only be edited by a superuser.

For this example we will not be setting up authentication requirements. You may wish to do so yourself, perhaps after you have gotten your share accessible without authentication. In /etc/default/nfs-kernel-server we will be setting NEED_SVCGSSD=no . This indicates that we don't need authentication.

In /etc/default/nfs-common we set NEED_GSSD=no because we are not using authentication, and NEED_IDMAPD=yes because we want to map user IDs from names (for properly preserving permissions). For that to work, 'idmapd' should be running and configured properly, something that it probably does by default.

In /etc/exports we will indicate that we want to use our newly created /exports/backupspace. We add something like /exports/backupspace,fsid=0,insecure,no_subtree_check,async) This should share /exports/backupspace, to the indicated subnet, with fairly standard settings and no authentication.

Restart the NFS service for the changes to have effect ( /etc/init.d/nfs-kernel-server restart should do it).

The client First, we need to determine where we will mount our network share (i.e., what path we will be using to access our files). This can't be done in an encrypted directory. I suggest using the location /media to create your mountpoint in, as this is the directory that storage devices are mounted to by the operating system itself. For this example I will be using /media/backupspace to mount my networked storage. sudo mkdir /media/backupspace

We install the client software: apt-get install nfs-common

We can manually mount our network share using the mount command: sudo mount -t nfs4 -o proto=tcp,port=2049 backupserver:backupspace /media/backupspace "-t nts4" indicates that we want to access something that is shared over nfs4. "-o proto=tcp,port=2049" are the default connection settings for the NFS service. "backupserver:backupspace" indicates which server and which share we will be using. Note that we do not list the server-side path here. The last part, "/media/backupspace", is the mountpoint on our client.

If we want to have the networked share to be mounted on boot we can use fstab, as shown earlier. We will use the flags "hard,intr". To quote the NFS how-to on the "hard" setting:

"The program accessing a file on a NFS mounted file system will hang when the server crashes. The process cannot be interrupted or killed (except by a "sure kill") unless you also specify intr. When the NFS server is back online the program will continue undisturbed from where it was. We recommend using hard,intr on all NFS mounted file systems."

( http://nfs.sourceforge.net/nfs-howto/ar01s04.html ) Since this is a backup system, it is crucial that we do not use the "soft" setting, which will lead to data corruption in such situations.

We will add something like the following to fstab: backupserver:backupspace /media/backupspace nfs rw,hard,intr 0 0 On my backup server I also have a share that is rarely written to. That share is itself not a backup, though a backup is created of it. Currently I mount it manually, but if I were to add it to fstab, I would have it mounted as read-only ("ro,hard,intr").

Some notes It is worth spending some time thinking about NFS security ( http://nfs.sourceforge.net/nfs-howto/ar01s04.html ). It is probably a wise idea to set up a firewall. You may wish to use a 'defense in depth' approach, and set up a firewall both for your network but also specifically on your NFS server machine. Currently I am using the rsync command to duplicate my files. This works fine. One downside is that there is no solid, pre-built way to handle filename changes. This isn't really surprising, without storing metadata there is no way to determine that a path has been adjusted. Instead, it concludes that items have been removed and that items have been added, and starts doing the same to the target location. If you are copying to an NTFS formatted target then it is important to know that NTFS doesn't support permissions.