Summary of common error messages of mount nfs

In the process of configuring the s3c-2410 development environment, I set up a shared directory for mounting during development, but various problems always occurred. It took me an entire afternoon to complete it, so I will summarize it here.

Usually when NFS cannot be used normally, a prompt will be given, generally the following types are given:

Permission denied

mount: 192.168.81.32:/opt failed, reason given by server: Permission denied

Check the exports configuration file to see if the client is allowed to mount.

errno = No route to host

mount: RPC: Unable to receive; errno = No route to host

First check whether they are in the same network segment

Then input:

[root@localhost etc]# service iptables status

Check if the firewall is turned on, if so, turn it off

[root@localhost etc]# service iptables stop

Note: However, this method sometimes still has some problems, so we simply turn off the firewall and selinux at the same time.

errno = Connection refused

mount: RPC: Unable to receive; errno = Connection refused

① First check whether the nfs service is enabled.

② Secondly, check whether rpcbind is enabled.

If rpcbind is not running, restart the nfs service after re-enabling rpcbind.

Because restarting rpcbind has affected some nfs configurations, it needs to be restarted.

Yes, you have found the problem.

[root@localhost etc]# service iptables stop

Then run service nfs restart.

The cross-compiled program in Linux needs to be run on arm, so first the program needs to be copied to arm, and nfs is selected.

But when mounting nfs on arm, I encountered a failure:

Find solutions online:

The default options for nfs mount include file locking and rely on the dynamic port allocation functionality provided by portmap.

Solution: kill file lock (lockd) or mount -o nolock

So I tried mount -o nolock -t nfs 192.168.1.24:/home/test /mnt/nfs and it worked fine.

not responding, still trying..

Sometimes errors occur when transferring large files.

NFS: server 192.168.81.32 not responding, still trying..

This may be a problem with NFS, which may be related to the size of the RING or buffer.

Cause analysis of the problem:

1. The default transmission protocol of NFS is UDP, and when the PC and the embedded system interact through UDP, serious network card packet loss will occur;

2. The transmission rates of the network cards of the server and the target machine conflict, which requires the target machine to spend a lot of time copying a large number of data packets. In fact, if the network card rate of the target machine is large enough, there is no need to divide so many packets and there will be no conflict.

Solution to the problem:

method one:

Use TCP protocol on the client side, use the following command, and add the parameter tcp to the mount command

mount -o tcp ,nolock 192.168.14.223:/nfs_root /mnt

You can also do this:

After tracing the code of fs/nfs/nfsroot.c, I found that when nfs is used as the root file system, the parameters can be written directly after "nfsroot=", and each parameter is separated by a comma, such as:

nfsroot=192.168.10.1:/rootfs,proto=tcp,nfsvers=3,nolock

This way you can specify nfs to use the tcp protocol

Method Two:

Specify the transfer rate (limit the size of data that can be read or written at one time during transfer)

mount -t nfs -o intr,nolock,rsize=1024,wsize=1024 192.168.14.223:/nfs_root /mnt

3. The card is in the connected state when mounted

Solution: If the network connection is normal, it may be that iptable or network firewall blocks TCP and UDP ports 111 and 2049 used by NFS. Taking ESX as an example, when you need to mount the NFS shared disk, you first need to edit the firewall security file to allow access to the port. Or simply disable the firewall

svc: failed to register lockdv1 RPC service (errno 111).

solution:

The default options for nfs mount include file locking and rely on the dynamic port allocation functionality provided by portmap.

Solution: kill file lock (lockd) or mount -o nolock

The mount was mounted with RW permissions, but read and write were still Permission denied.

After restarting the NFS service, on the client

mount -o tcp,nolock 192.168.10.77:/home/gatieme/Work/NfsRoot /mnt/nfs

The command mounts the network file locally. After the execution is completed, the directory is accessible, but not writable. It feels a bit strange, because the command clearly specifies that it can be written.

So I searched for information online and found that there is a parameter no_root_squash in the exports directory permissions.

Its function is: if the user who logs in to the NFS host and uses the shared directory is root, then he will have root permissions for the shared directory! .

By default, the opposite parameter root_squash is used.

If the user who logs into the NFS host and uses the shared directory is root, the user's permissions will be compressed to an anonymous user, and usually his UID and GID will become nobody.

Because my client is logged in as root, the permissions are compressed to nobody, no wonder it cannot be written. Change the configuration information to:

/home/gatieme/Work/NfsRoot 192.168.10.123(rw,no_root_squash)

It was said to be a bit unsafe, but the problem was solved.