Print

General NFS Troubleshooting

Linux and Mac NFS Issues

A Linux share to a Mac needs the insecure option set in linuxsrv:/etc/exports
/etc/exports snippet
/dir_to_share   192.168.0.0/24(...,insecure,...)

Historically NFS clients communicate from a reserved client port (ie one that requires root access - typically a port number < 1024). This provided some additional security in that it prevented users from running their own copies of NFS clients (on non-reserved ports). Most NFS clients (!?) still communicate from a reserved port, except...Apple...
The Linux server appears to accept the connection request because it logs "mountd[6978]: authenticated mount request from 192.168.0.99:" etc.
However by default the Linux NFS server uses secure mode and thus silently rejects the connection. The Apple mount client reports "Operation not permitted".
IMHO the name of this option is overly strong for current network usage patterns, especially as an alien machine with mount access would provide root access to it's owner negating the implied protection.

There is another solution to this, useful if the server cannot be modified - the nfs client can use the -o resvport option on the mount command. This forces the client to comply with the server's requirement of a port < 1024.

Linux and Solaris Issues

Failure to mount Linux (NFS v3) share on Solaris 10.
If you try to mount an share from a recent (2.6 ?) Linux kernel using NFS v3 you might get the following error:
mount -F nfs -o vers=3 192.168.0.40:/ /tmp/dir
nfs mount: server 192.168.0.40 did not return any security mode

This particular error message is a relatively recent Solaris change in response to what appears to be a bug in the Linux nfs server. The linux nfs server is not returning any security modes (eg ie AUTH_SYS etc) which means Solaris fails to negotiate a security mode. I don't know the workaround to this - except avoiding NFS v3 in this situation.

Failure to mount Linux (NFS v4) share on Solaris 10.
So you've exported some Linux shares as you have done on unix for years, but you just can't mount them on Solaris 10... Every time you try you get No such file or directory.
The problem may well be as follows:
NFS v4 has a distinct concept for exported filing system namespaces (ie paths) that does not necessarily map directly to the normal unix paths. In particular in Linux the "exported root" (ie what is treated as the first "/" in any client mount command is not necessarily the servers' root directory.
It gets complex, but the simple view is this:
  • Collect all your exports under a common path. They may already be under say /export. It is generally better if "/" is not your common path - else you have to export your entire filing system. If the actual directories to be exported are scattered around the filing system and cannot be moved, then they can be virtually collected under a common point in Linux using the "mount --bind" option which I tend to think of in simple terms as rather like a hard link.
  • Now this common path is going to become the "exported root" (in the example below it is /export
  • Export the other directories as normal (although one could omit them if the common root suffices)
  • The solaris client must use mount points treating the "exported root" as "/"
/etc/exports
/export  192.168.0.0/24(fsid=0, ....)
/export/my_export_path_A   192.168.0.0/24(....)
/export/my_export_path_B   192.168.0.0/24(....)

In the snippet above we set /export as the NFSv4 export root using the option fsid=0. It should only be used in one place. Running exportfs -ra as necessary we can now mount my_export_path_A as
Solaris mount command
mount -F nfs server:/ /local_mount_point
or
mount -F nfs server:/my_export_path_A  /local_mount_point

NOTE: the following is incorrect mount -F nfs server:/export/my_export_path_A /local_mount_point

General NFS Issues

Hostname resolution
There can be issues when an NFS server (or client) cannot correctly map between a client/server IP address and FQDN. It is probably best to ensure all NFS server and clients have resolvable FQDNs. Whilst running some form of name server in a local network is preferable, a simple (but harder to maintain) solution is to ensure a set of /etc/hosts entries shared between client and server. It may be necessary to put the FQDN entry first in the hosts file:
/etc/hosts snippet
192.168.0.2   mynfsserver.mydomain.net  mynfsserver
192.168.0.32  mynfsclient.mydomain.net  mynfsclient

YMMV. Other websites discuss this in more detail, I suggest googling "NFS name resolution" for information.


  • + : A leading plus sign indicates that this word must be present in every object returned.
  • - : A leading minus sign indicates that this word must not be present in any row returned.
  • By default (when neither plus nor minus is specified) the word is optional, but the object that contain it will be rated higher.
  • < > : These two operators are used to change a word's contribution to the relevance value that is assigned to a row.
  • ( ) : Parentheses are used to group words into subexpressions.
  • ~ : A leading tilde acts as a negation operator, causing the word's contribution to the object relevance to be negative. It's useful for marking noise words. An object that contains such a word will be rated lower than others, but will not be excluded altogether, as it would be with the - operator.
  • * : An asterisk is the truncation operator. Unlike the other operators, it should be appended to the word, not prepended.
  • " : The phrase, that is enclosed in double quotes ", matches only objects that contain this phrase literally, as it was typed.

Categories

Related Sites

Toolbox

Print