Getting NFS serving to work on Fedora 20 eluded me for quite some time, and since I rarely ever needed that box to serve a directory through NFS, I didn't put a great deal of time and effort into it. On the other hand, it happily let me use NFS to access directories exported from other computers. So I let sleeping dogs lie.
Eventually, I decided to do something about it, especially as the stop-gap measure was less than acceptable: Shut down the firewall, establish a NFS connection, then put the firewall back up again (once the connection was made, the firewall doesn't stop further connections).
Here's what worked, in the most pain-free way of fixing the problem. Run the firewall config program, and allow the mountd, nfs, and rpc-bind services, and make sure that that they get saved as permanent settings (if you don't, they're temporary settings that are forgotten when the computer is shutdown or rebooted). That opens up TCP and UDP ports for ports 20048, 2049, and 111, respectively. Naturally, those services have to be running, too, but they haven't required any custom configuration of their daemons.
If you don't know where to find the firewall configurator, you can
start it with the firewall-config command. I'm not
sure if that's installed if you don't use Gnome or mate (which I
do). If you don't have it, then use your firewall configurator to
do the same thing (either enable those services, or those ports).
And that (after the initial configuration /etc/exports
file of the NFS server, regarding which directories
to share out), was all that I had to do to the machine acting as a
NFS server (the one exporting some of its directories to my
LAN). What caught me out was not knowing about the
mountd server. It was obvious I had to allow the
NFS server through the firewall, simply because of the name,
and I worked out that I needed to allow the rpc-bind,
because rpc came up while searching through my computer for
NFS-related things, but mountd did not.
In the “this works for me” category, here's some background information:
I am using the “autofs” automatic mounter thingummy on other Fedora installations (the ones accessing this server) to automatically connect to exported NFS directories when you try to access them through a special filepath structured like this:
/net/hostname/exportname/filepath/filename
Where “/net” is a directory on the client machine, “hostname” is replaced by the hostname of the NFS server (local machinename resolution has to work, for this to work), “exportname” is the name of its exported directory, and “filepath/filename” is the filepath and filename of the desired file within that exported directory.
e.g. less
/net/mainbox/home/tim/sample.text
The system recognises that accesses to /net are special, and parses the rest of the request to work out how to deal with it.
This means I don't have to have permanent mounting entries in the
/etc/fstab file (which can be a problem if the server isn't permanently
available). The mountpoints inside the /net directory are
created on-demand when you try to access the filepath—whether that be on
the command line (such as using cd, ls, or any
other command), or through program's GUI file requesters
(loading from, or saving to, that filepath). If the “/net”
directory is not there, you'll need to create it.
In my case, local computer hostnames are resolved by our
LAN's DNS server, but you can use the
/etc/hosts file for LANs without one, and some
LANs have other services which handle same function as a
DNS server.
That's pretty much all I've had to do to be able to access other NFS servers, other than ensuring that the sane user accounts are used on both sides of the equation. That means the user-id numbers match, not simply the user-names. In fact, it doesn't matter if the names are different, because only the user-id numbers are used. While it's supposed to be possible to get NFS to match user-names against different user-ids, I've not really looked into how to do that, and our LAN has a range of different operating systems and hardware devices, that mayn't support that feature.
For the user “tim” on one computer to be treated as the same “tim” user on the server, so that files transferred are owned by the same person, so that file-permissions make sense, make sure that his username is applied to the same user-id numbers on each side (server and client).
Some people might suggest using Samba, instead. But I've found that to be slower to transfer, more convoluted to configure (e.g. having to add users to the Samba configuration on every client machine), and it's a foreign protocol shoe-horned into Linux. Plus it suits me that a visiting foreign Windows computer won't be able to horse around with any file sharing system (SMB's browse-master election system frequently wreaks havoc on LANs).
/etc/exportsNFS doesn't not use authentication, so doesn't provide any security to stop someone pretending to be another user from doing what that user could do. It relies on properly configured clients to do their own local user control. So rogue users can masquerade as other people if they're able to configure the user-accounts on their computer, or if they're able to connect their own personal computers to your LAN (which could be configured completely at their whim). So it's only suitable to use this protocol on a completely trustworthy LAN, or on a LAN where there is no need to control access and identity (e.g. you could have a public read-only exported directory for downloading public files).
I believe it's possible for NFS version 4 to have user-restrictions that stop this, but you have to configure all your NFS servers to use that version, and only allow that version of the protocol. Naturally, this means that all the clients must be able to use version 4, as well, which may not be possible.
For untrustable networks, you need to use a different protocol. Such as SMB, which requires remote users to log-in to the server, for access.