NFS Service under Linux

1. What is NFS (Network FileSystem)
NFS is the abbreviation for Network FileSystem, which was first developed by Sun. His biggest function is to be able to use the network, so that different machines, different operating systems, can share the individual files (share file), so you can simply think of him as a file server! This NFS Server can let your PC to the Network remote NFS host share directory, mount to the local side of the machine, so, on the local side of the machine looks, the remote host directory as if it is their own partition general!
While NFS has its own protocol and port number used, NFS uses a protocol called Remote Procedure call, RPC to assist in the operation of NFS itself when transmitting data or other related messages.

2.RPC
  When we use some services for remote online, some information, such as the host's IP, service  port number, and the corresponding services  PID  and so on, need to manage and correspondence! These management  port  correspondence and service-related work is the task of this  Remote Procedure Call, RPC .
 nfs The service of   itself does not provide a protocol for data transfer, but  NFS  allows us to share the file, and the reason for this is that  NFS  use some other relevant transport protocols! And these transfer protocols are used to this so-called  RPC  function! This means that, nfs  itself is a  program  of using  RPC ! Speak a little more vernacular, nfs  can also be regarded as a  RPC server ! Also note that in some situations, not only the  NFS   Server  need to activate  RPC  services, together, to Mount  nfs partition    Client  machine, also need to synchronize the activation  RPC ! This way the  Server  and  Client  will be able to do the  program port  correspondence with the  RPC  protocol. nfs  mainly in the management of the share of the directory, and as for the transfer of information, he lost to the  RPC  agreement to operate it!

3.NFS activated RPC daemons
O RPC.NFSD: The main function of this daemon is to manage the Client's ability to access the host, which also includes the identification of the login ID.
O Rpc.mountd: The main function of this daemon is to manage the NFS file system! After the client has successfully logged into the host through RPC.NFSD, he will be authenticated by the file usage rights (that is, the-rwxrwxrwx and owner, the group's permissions) before he can use the files provided by NFS server. He's going to read the NFS profile/etc/exports to the client, and after that, the client can get permission to use NFS files! (Note: This is where we use permissions and security settings to manage the NFS share directory.)

4.NFS requires two packages, respectively:
Nfs-utils
is to provide RPC.NFSD and Rpc.mountd two NFS daemons and other relevant documents and documentation, execution files and other packages! This is the main kit for NFS.
Portmap
  As we just mentioned, our  NFS  can actually be regarded as a  rpc server program, and to activate any one  rpc server  program  before, we need to do  port    ( mapping )   work, this job is actually " portmap   "This service is responsible for! In other words, we need to activate  portmap  before activating any  RPC server ! So what is this  portmap  doing? Just like the name of this service, haha! is to make  port   mapping  Ah! For example: When the  Client  tries to use the services provided by  RPC server , because  Client  needs to get a  port that can be connected   is able to use the services provided by  RPC server , so, client  first goes with  portmap  say "Hello!" Could you please give me a  port number&nbsp, so that I can contact  RPC ? "This time  portmap  will automatically manage its own  port mapping  inform  client  so that he can connect up  server   It! So: "Before activating  NFS , please activate  portmap ! 』

5.NFS server-side settings:
a)./etc/exports
Shared directory host name 1 or IP1 (parameter 1, parameter 2) hostname 2 or IP2 (parameter 3, parameter 4)
b). Parameters
RW: rewritable permissions
RO: Read-only permissions
No_root_squash: Login to the NFS host using the share directory of the user, if it is root, then for this shared directory, he has root privileges! This project is "extremely unsafe" and is not recommended for use!
Root_squash: When the user who is logged in to the NFS host using the shared directory is root, then the user's permissions will be compressed into an anonymous user, usually his UID and GID will become nobody that identity;
All_squash: Regardless of who is logged in as the user of NFS, his identity will be compressed into an anonymous user, usually nobody!
Anonuid: The UID setting value of the anonymous user mentioned in the previous *_squash, usually nobody, but you can set the value of this UID yourself! Of course, this UID must exist in your/etc/passwd!
Anongid: Same as Anonuid, but become group ID just
Sync: Data synchronously written to memory and hard disk
Async: Data is stored in memory rather than directly to the hard disk

6. Set the instance:
a)./tmp * (Rw,no_root_squash)//* indicates that all IPs can be accessed
b)./tmp * (rw)
/home/public 192.168.0.* (rw) * (RO)//The following two lines act like
/home/public 192.168.0.0/24 (rw) * (RO)
c)./home/test 192.168.0.100 (rw)//Set permissions on only one machine
d)./home/linux *.linux.org (rw,all_squash,anonuid=40,anongid=40)//when *.linux.org lands on this NFS host and writes files under/home/linux, The owner of the file and all the groups will become the user of that identity with the UID 40 in the/etc/passwd.

7. Permissions issues
Suppose the contents of the/etc/exports are
#vi/etc/exports
/tmp * (Rw,no_root_squash)
/home/public 192.168.0.* (rw) * (RO)
/home/test 192.168.0.100 (rw)
/home/linux *.linux.org (rw,all_squash,anonuid=40,anongid=40)
Suppose we landed this NFS host (192.168.0.2) on the client side of 192.168.0.100, then
Situation one: In 192.168.0.100 's account is the identity of the test, at the same time, the NFS host also has test this account
a). Because the/TMP permission for the NFS host is-RWXRWXRWT, I (Test on 192.168.0.100) has access permissions under/tmp and everyone writing the file is test.
b). In/home/public, because I have permission to read and write, if the NFS host's permissions on the/home/public directory are open to test, then it can be read and written, and the owner of the file is test. If the/home/public for the NFS host does not have write access to the test user, it cannot be written, although the/etc/exports is RW and does not work.
c). In/home/test, the permissions are in the same state as/home/public, and the/home/test for the NFS host requires open access to test.
d). In/home/linux, no matter what kind of user, the identity will be turned into the uid=40 account.
Scenario Two: If we are test2 in 192.168.0.100, but the NFS host does not test2 this account
a). It is still possible to write in/tmp, but the file owner is written into nobody.
b). In/home/public and/home/test whether can write, also need to see/home/public permission, but identity is turned into nobody
c) The identity under the/home/linux or become uid=40 account.
Scenario Three: Identity as root in 192.168.0.100
a). In/tmp can be written, but due to the parameters of No_root_squash, changed the preset value of Root_squash, so in/tmp to write the file owner is root.
b). The identity under the/home/public is compressed into nobody, because the preset properties all have Root_squash, so the file owner becomes nobody.
c). The/home/test situation is the same as/home/public.
d). In/home/linux, the identity of root is also compressed into the uid=40 user.

8. Start the service Portmap,nfs
 #/etc/rc.d/init.d/portmap start   (or: #service  portmap  Start)
 #/etc/rc.d/init.d/nfs start    (or: #service  nfs start)
  You can go inside the/var/log/messages to see if the
9.exportfs usage is activated correctly
  If we have modified/etc/exports, we do not need to restart the NFS service, as long as the EXPORTFS is re-scanned/ Etc/exports, and Reload
  syntax:  exportfs [-aruv]
 -a:  mount all (or uninstall)  /etc/ Exports the settings in the file
 -r:  re-mount/etc/exports inside the settings, also sync updates/etc/exports and/var/lib/nfs/xtab contents
 -u: Uninstall a directory
 -v: When you export, the shared directory is displayed on the screen.
  Example
  #exportfs  -rv //re-export
  #exportfs  -au //all uninstall

10./var/lib/nfs/xtab can view the sharing permissions for each directory (but I did not find, rely on, found, originally want to someone mount NFS after the content), such as:
/tmp Node3 (ro,sync,wdelay,hide,secure,root_squash,no_all_squash,subtree_check,secure_locks,mapping=identity, ANONUID=-2,ANONGID=-2)
Why Anonuid=-2? Oh! In fact it is said to be 65536-2 of the value, that is, the UID of 65534! Compare/etc/passwd, and you'll find, wow! Turns out that's nobody.

11.showmount command
Syntax: showmount [-AE] hostname
-A: Displays the status of the current directory used by the host and client
-E: Displays the directory shared within the hostname/etc/exports

12. View the activated PortNumber
  #netstat  -utln
 nfs  The  port  you have opened, the  2049  port  of  ! Is that  NFS  mainly produces  port NFS server  in the front we mentioned, he is a kind of  RPC server , and   nfs  due to the availability of multiple  program  (  such as  RPC.MOUNTD,  rpc.rquotad, rpc.nfsd... )   So you need to activate multiple  port ! And these  port  are "randomly generated", that is, the  port number  will not be fixed! Each  restart nfs  will get a different  port number ! So how do  Client  know to connect to that  port  to call the  program ? Oh! That's what  sunrpc  ( port 111 )   that  portmap  service generated by  port number  The Function! client  will connect to  sunrpc  that  port  to know the program that needs to go to that  port  to call! So, rpc.xxxx  and so on  daemon  nature does not need to have a fixed  port number !

***********************************************
Settings for NFS Clients
#mount-T NFS hostname (ORIP):/directory/mountpoint, it's that simple.
In order to worry about accidentally the NFS side of the program with the SUID privilege file is executed, root can share the NFS shared directory in a more secure case, you can
#mount-T Nfs-o nosuid,ro Hostname:/directory/mountponit

Possible problem areas:
1. Permissions are not set to match
2. Forgot to activate the Portmap, this will be an error:
Mount:RPC:Port Mapper failure-rpc:unable to receive or
Mount:RPC:Program not registered
Then, start Portmap, and restart NFS
#service Portmap Start
#service NFS Restart
3. Get rid of the firewall
The firewall was reset, including Iptables and Tcp_wrappers, because Portmap was activated, so Port 111 had to be provided. Therefore, in the Iptables rules, add:
Iptables-a input-p TCP--dport 111-j ACCEPT
Iptables-a input-p UDP--dport 111-j ACCEPT
If not, that is tcp_wrappers problem, check/etc/hosts.deny, if there is a line:
ALL:ALL:deny
It must be added in the/etc/hosts.allow:
Portmap:ALL:allow
If our NFS is developed for internal networks, for external networks only for academic network development (140.0.0.0/8), you can:
Iptables-a input-i eth0-p tcp-s 192.168.0.0/24--dport 111-j ACCEPT
Iptables-a input-i eth0-p udp-s 192.168.0.0/24--dport 111-j ACCEPT
Iptables-a input-i eth0-p tcp-s 140.0.0.0/8--dport 111-j ACCEPT
Iptables-a input-i eth0-p udp-s 140.0.0.0/8--dport 111-j ACCEPT
You can also use Tcp_wrappers to specify the host IP and name of the NFS host in/etc/hosts.allow, for example
#vi/.etc/hosts.allow
Portmap:192.168.0.0/255.255.255.0:allow
Portmap:140.113.23.23:allow
Portmap:. Sdu.edu.cn:allow

Related commands for RPC server
Rpcinfo
#rpcinfo-P hostname (ORIP)

Issues to be aware of:
It is important to note that because this RPC used by NFS on the client side of the host, then your host wants to shut down, it will become an "impossible task"! I don't know what the right reason is, but if you have a Client on your Server that's online, you might have to wait a few hours for the shutdown to be successful! Crunch It's a real fake! Don't you believe it? Or you try it yourself! ^_^! So, it is recommended that your NFS Server will be able to "turn off Portmap and NFS" Before you shut down the computer for two things! If the two daemons can not be properly turned off, then first NETSTAT-UTLP to find the PID, and then kill him off first! This way can be a normal shutdown success Oh! Please pay special attention to this!

In TurboLinux8.0 for AMD64 (kernel 2.4.21-4SMP), Mount NFS has the following error:
Portmap:server localhost not responding, timed out
Workaround:
Mount-t Nfs-o nolock Node1:/public/public
That is, increase the-o nolock parameter, the reason:
UNFSD doesn ' t support NLM locking, and it's causing the LOCKD daemon to be started (which again requires the PORTM

NFS Service under Linux