NFS (EXPIRTFS command, the NFS client creates a new file that belongs to the group and the owning master is nobody)

First, Exportfs command

The NFS process cannot be started randomly, and if it has to be restarted, the client's mount directory must be uninstalled and then restarted.

Then you can use the Exportfs command.

-A all mount or uninstall all

-R Re-mount

-U Uninstalls a directory

-V Show shared directory

Experiment:

We configure the configuration file on the server side from the new line

[Email protected] nfstestdir]# Vim/etc/exports

/TMP/192.168.52.100/24 (Rw,sync,no_root_squash)

Then use the EXPORTFS command

[Email protected] nfstestdir]# Exportfs-arv

Exportfs:no options for ~: Suggest (sync) to avoid warning

Exporting 192.168.52.100/24:/tmp

Exporting 192.168.52.100/24:/home/nfstestdir

Exporting: ~

We look at the client:

[[email protected] ~]# showmount-e 192.168.52.101 (at the moment we find that the NFS service has not been restarted, but the configuration file is still updated)

Export list for 192.168.52.101:

/tmp 192.168.52.100/24

/home/nfstestdir 192.168.52.100/24

Ii. issues with Client for NFS

There are more than one encountered in Centos6, the NFS4 version may have this problem

After the client mounts the shared directory, either root or normal user, the owner of the new file is created and the group is nobody.

Workaround:

The first type:

Client hangs on with-O nfsvers=3 (specifies NFS version 3)

The second type:

Both the client and the server have to do:

vim/etc/idmapd.conf//

Change "#Domain = local.domain.edu" to "Domain = xxx.com" (xxx.com here, define it arbitrarily), and then restart the RPCIDMAPD service

NFS (EXPIRTFS command, the NFS client creates a new file that belongs to the group and the owning master is nobody)