Introduction

Network File System (NFS) is a network file system protocol that allows a user on a client computer to access files over a network as easily as if the network devices were attached to its local disks. In more complex networks it can be easier to automate attaching of remote NFS disks via mechanism like autofs (it can e.g. solve server/client boot order dependency present in /etc/fstab method).

MEPIS by default is missing several packages. The nfs-common, nfs-utils package available here and nfs kernel portion are missing. Also portmap is necessary for proper NFS functioning. Finally, be sure to add the nfs port to the guarddog firewall or the server will not work. Don't install the nfs userspace utility as this will cause problems. Use Ksysv to add portmap and the nfs-common package at runtime.

NFS Setup

This section will cover the Network File System (NFS) and will walk you through the basics of implementing NFS on a home or small business network. The network setup described within will not necessarily match your home/business configuration, but is designed to assist in ease of implementation. The specifications of this mock network are as follows:

- A primary user (mepisfan) that will benefit from file sharing provided by NFS.

NOTE: If DNS is setup, you can use the machine hostname versus the IP address. The DNS described below as "DNS via /etc/hosts" has been tested and works, this tutorial will mainly cover IP in an effort to keep the concepts described below as simple as possible to understand (as well as in the case DNS is not setup/working correctly on your network). Also, most modern router/switch combos come with Address Reservation via DHCP capability, so your machines do not necessarily need to have static IP's assigned for this tutorial to work.

This section will be split into three sub-sections, Access Permissions, Server Setup, & Client Setup, to be followed in progression. This tutorial also assumes that you want client systems to connect to the shares on a dedicated server machine. If you want two way sharing between two clients only, the setup is different. Also, this configuration has not been tested with a desktop firewall such as Guarddog or Firestarter.

Access Permissions

NFS user permissions are based on user ID (UID). UIDs of any users on the client must match those on the server in order for the users to have access. So, all client users needing access to the server shares have to be setup on the server for proper access rights. For example, if mepisfan has a UID of 1001 on the client, then a user mepisfan has to be created on the server with a UID of 1001 with the same password as the client user. This HowTo (at the moment) will not cover the synchronization of passwords and will assume this will be handled manually. Also, keep in mind that with NFS, a user's access to files can be determined by his/her membership of groups on the client, not on the server. However, only a maximum of 16 groups can be passed from the client to the server.

Configuration

Portmap Lockdown

This will block all connections to your server. Only machines listed in "/etc/hosts.allow" will be permitted to connect to shares on the server.

Edit "/etc/hosts.allow" as root and insert:

portmap mountd nfsd statd lockd rquotad : 192.168.0.3 192.168.0.4

This will allow the client machines 192.168.0.3 [mepis1] & 192.168.0.4 [mepis2] to connect to the nfs shares.

DNS via /etc/hosts

This will configure basic DNS between the systems on your network. This is required for nfs to work. It is also important if you want to use hostname (i.e. mepis1, mepis2, etc) instead of IP (i.e. 192.168.0.3, 192.168.0.4, etc) for the systems on your network.

Edit "/etc/hosts" as root and insert the following lines:

127.0.0.1 localhost (default, should already appear)
127.0.0.1 mserver (default, should already appear)
192.168.0.2 mserver (needed, this will allow nfs to function correctly, as well as if DNS servers go down, if you have a DNS Server)
192.168.0.3 mepis1 (needed, identifies that the system mepis1 uses 192.168.0.3 as an IP)
192.168.0.4 mepis2 (needed, identifies that the system mepis2 uses 192.168.0.4 as an IP)

This identifies which directories the server will share to the clients, and allows them to mount the following shares from the server. At this time you will want to make sure that the desired users/groups have permissions on the shared directories. In the above example, ro makes the share read only, rw makes the share read/write, and sync will allow for basic communication from the server to the clients regarding available files.

Export Shares & Restart Services

If this is not done, new shares will not be available to client machines, so anytime "/etc/exports" is modified you will want to export the shares and restart the related services portmap & nfs-kernel-server:

DNS via /etc/hosts

Mounting Shares

NOTE: You will want to create directories on the client so you have mountpoints for your shares. Creating these directories in your home folder is suggested (i.e. /home/%username%) will ensure that user has appropriate rights, if you choose to mount the shares else where you will want to make sure the user has rights to those directories.

Manually in konsole

This method is suggested if you have a laptop that you use for travel.

Reboot. Shares will automatically mount on startup and will be available via your favorite file manager.

NOTE: Automatic NFS mounting via /etc/fstab can lead to problems. To use NFS, the server must be up and running before the client can boot and mount NFS shares at startup. This is OK when the server is running all the time and contains important data - so important that running the clients without access to shared data does not make much sense anyway. It is however unacceptable to create this boot order dependency just because of some casually shared data, like photo folder on your friend's laptop. When two computers are to export NFS shares to each other, this fstab method is even impossible - each of them would have to boot before the other one. In these cases, methods like autofs provide the solution.

MX-14

This guide details NFS File sharing between MX-14 and another Linux computer. It does not provide security. That is no login is required on any machine on the network to see the shares.

Installation

nfs-common and nfs-server are installed in MX-14. They should be installed on the Linux machine you intend to share with. If that machine is only to be the client then only nfs-common needs to be installed.

Make the shares on the server

One computer must be designated as the server, and then set up as follows:

As user, make the share drirectory on the server, where share is the name of the folder you are sharing.

Mkdir /home/<username>/share

As root edit /etc/exports adding a line containing your share. This line will vary depending on your goal:

--For everyone read/write

/home/<username>/share (rw,sync,no_subtree_check)

--For one specific device read/write

/home/<username>/share 192.168.1.200(rw,sync,no_subtree_check)

Note that the first three digits of the IP address may be different and should match your network.
--For a network read/write

The folder share in your home directory can now be seen by the client in your file manager.

Notes

1. To make this a permanent mounted share, edit, on your client, /etc/fstab as root as follows:

<server_ip_address>:/<server_share_name> /media/nfs-server nfs rw 0 0

2. The server setup can be done on any client machine on the network as well to setup two way sharing.

Compiling NFS-Utils

When compiling the nfs utils, you will need to use the --enable-nfv4=no and a couple of the others that will return errors when compiling nfs-utils, as the libraries used are not necessary for nfsv3 or v2. One is the GSS libraries. There are also a number of components that need to be added, just do an apt-cache search for the dependencies that are missing. It does not appear that the nfs-utils are anywhere within the synaptic package tree. Some tweaking of the ./configure script will get things built.

Finally, when putting entries for NFS into fstab, be sure to put them BEFORE the dynamically generated ones, or they will go away each boot time.