A good Article about NFS

What is NFS (network filesystem)
　
Before we start the NFS Setup, let's take a look at what NFS is. It's no use talking about a bunch of them, right. ^_^. The so-called NFS is the abbreviation of network filesystem, which was first developed by the Sun company. His biggest feature is the ability to share individual files (share file) with different machines, different operating systems, and other networks, so you can simply think of him as a file server. This NFS Server allows your PC to share the directory of Remote NFS hosts on the local side of the machine, so the machine at the local side looks like the directory of that remote host as if it were a disk split slot (partition). Use the above very convenient.
As shown above, when our NFS Server has set up the shared/home/sharefile directory, the other client side can mount the directory to a mount point on its own system (mount point can be customized.) , for example, the Personal Computer 1 in the previous illustration is not the same as the Personal Computer 2 mount. As soon as I enter/home/data/sharefile within the Personal Computer 1 system, I can see all the data in the/home/sharefile directory within the NFS Server system (and, of course, the permissions are sufficient.) ^_^). This/home/data/sharefile is like my own Personal Computer 1 inside of a partition Oh. As long as permissions are right, then you can use CP, CD, MV, RM ... And so on disk or file-related directives. It's his x's convenience.
　
Then you may ask: "Gee." So what kind of protocol does this NFS transmit? "Although NFS has its own protocol and the port number used, NFS uses an agreement called Remote Procedure call (remotely Procedure calls, RPC) to assist in the operation of NFS itself when data transfer or other related messages are delivered. 。
　
What is RPC (Remote Procedure Call)
　
So what is RPC? by literal means "remote procedure call" is not the program that some programs (program) need to use when performing remote online. Oh. Yes, that's right. In simple terms, when we use some services for remote online, some information, such as the host's IP, the service port number, and the corresponding service PID, etc., need to manage and correspond. These management port's correspondence with the service relevance work, is this Remote Procedure call, RPC's task.
　
Okay, if we connect NFS to RPC, then you should know that the Service for NFS itself does not provide data delivery protocols, but NFS allows us to share files, which is because NFS uses a number of other related transport protocols. And the protocol of these transmissions is to use this so-called RPC function. That is to say, NFS itself is a program that uses RPC. In a more vernacular sense, NFS can also be considered an RPC server. Also note that in some cases, not only the Server running NFS needs to start RPC services, and, to mount NFS partition Client machines, it is also necessary to start RPC synchronously. So that the Server and client can be RPC protocol for the program port of the corresponding OH.
　
Ok. Simply put, NFS can also be viewed as a kind of RPC server, because he is the program that uses this protocol. ^_^. So why is NFS executed using RPC? This is because NFS itself can be viewed as a file system, in that case, your users often change online, and your file content, shared directory, and other file-related information, and so on, will often change, at this time, use similar to the program number and RPC on port number is quite handy. That is, NFS is primarily in the management of shared directories, and as for the transfer of data, it is simply the protocol that he throws to RPC to operate.
　
For more information on NFS protocols, you can refer to the following pages:
Http://www.faqs.org/rfcs/rfc1094.html http://www.tldp.org/HOWTO/NFS-HOWTO/index.html
NFS-initiated RPC daemons
　
NFS server needs to be enabled in total to at least two daemons, one to manage whether the client can log in, and another to manage the file permissions that the client can use after the login to the host. If you want to manage quota, then NFS will automatically reload other related RPC program. The easiest way to set up NFS here is as follows: RPC.NFSD: The main function of this daemon is to manage the Client's ability to log on to the host, which also includes the ID of the login. RPC.MOUNTD: The main function of this daemon is to manage NFS file systems. Once the client has successfully logged into the host via RPC.NFSD, he will have access to the file (the-rwxrwxrwx and owner, group privileges) before he can use the files provided by NFS server. He would read NFS's profile/etc/exports to the client, and after that, the client would get permission to use NFS files. (Note: This is where we use permissions and security settings for managing NFS-shared directories.) Required Kit to start NFS we have to have two kits to do this, respectively: Nfs-utils and nfs-utils-clients (sometimes only one) Portmap Portmap：
As we've just mentioned, our NFS can actually be treated as an RPC server program, and before we start any RPC server program, we need to do the work of port (mapping), and this job is actually " Portmap "This service is responsible for. That is, we need to start portmap before we can start any RPC server. So what is this portmap doing? Just like the name of the service, haha. is to make port mapping ah. For example, when the client tries to use the services provided by RPC server, the client needs to obtain a port that can be connected to use the services provided by RPC server, so the client first goes to the Portmap and says, "Hello 。 Could you please give me a port number so that I can contact RPC? "This time Portmap automatically will own management of the port mapping inform the Client, so that he can connect to the server." So: Before you start NFS, start Portmap. 』 nfs-utils:
is to provide RPC.NFSD and rpc.mountd of these two NFS daemons and other related documents and documentation, execution files, etc. kits. This is the main kit for NFS. Be sure to have a oh. Well, after you know what we need these two kits, what do we do now? Let's go to your system first use RPM to see if there are any of these two kits. If not, quickly use RPM to install OH. Or else we can't play it anymore.
　

Examples: My host is a Linux distribution with RPM as a suite, such as Red Hat, Mandrake and OpenLinux, so how do I know if I have a portmap NFS-related kit installed in my host? A: Simple use of Rpm-qa | grep NFS and Rpm-qa | grep Portmap can know.

Server-Side settings: NFS Suite structure
　
NFS This is really very simple, the above we mentioned in the NFS suite, the profile is only one, the execution file is not much, the record file is twos and threes. Let's take a look first. ^_^
　 /etc/exports: This file is the main profile for NFS. However, the system does not have a default value, so this file "does not necessarily exist", so you have to use VI initiative to build this file OH. We're just going to have to talk about a setup that's only the file.
　 /usr/sbin/exportfs: This is an instruction to maintain NFS-sharing resources, and we can use this directive to share/etc/exports changed directory resources, uninstall or recycle directories shared by NFS Server, and so on, which is a very important part of the NFS system. As for the instructions, we will introduce them at the bottom.
　 /usr/sbin/showmount: This is another important NFS directive. The EXPORTFS is used on the NFS server side, while the showmount is used primarily on the client side. This showmount can be used to view the directory resources shared by NFS.
　 /var/lib/nfs/xtab: This file is the main NFS record file. When our NFS shares the directory resources, which client side once connected to our NFS host. Oh. Just look at the contents of the file. ^_^
Just say it's not difficult. These are the main ones.
　
Planning tips for Hosts
　
If you have multiple Linux hosts in your work environment and you expect to share your catalogs with each other, it is best to plan a partition as a reservation when installing Linux distribution. Because NFS can be shared for directories, you can mount the reserved partition at any one mount point, and then mount the point (that is, the directory). shared by/etc/exports, other Linux hosts in the entire work environment can use the reserved partition of the NFS host. Therefore, in the mainframe planning above, the main need to pay attention to only partition. In addition, because the sharing of the partition may be more vulnerable to intrusion, it is best to set the partition more stringent parameters in the/etc/fstab Oh.
　
Setup process (/etc/exports)
　
We explained a little bit about NFS in part of the principle, wow. It looks as if the powder is hard. In fact, not at all. Why, then? Because Portmap as long as a scripts can be activated, NFS as long as the setting of a file can operate smoothly. So how can we say it's not easy. Oh. This NFS is really his wife of X ... Simple ~ before starting NFS, let's take a look at the entire process with "resource sharing" in the Windows system:
On the Windows Server, open the File Explorer, right-click on a directory to choose to start resource sharing, and in the content of the resource share, set the "User Rights" (for example, Windows 2000); Log in to Windows Server on the client side , you need to start neighbor on the network to find the directory that is shared on the available network, and then click the directory, and if you can log in to the Windows server, you can use the files in that directory according to the permissions of step one.
Oh. That's right. The whole process of NFS is similar:
First, you need to make sure that your Linux host can support the NFS service, and then set the user's source IP or host name and the permissions to share the directory, and then start NFS to share the directory you just set up. So how to use this shared directory on the client side. is to showmount this program to check whether the Linux Server has an available NFS directory, if any, it will mount on the top of the machine, if you can mount, then you can use the resources provided by the NFS host.
Ha ha. It's easy enough. So let's take a step at the bottom to explain how NFS is set up:
System requirements/etc/exports about permissions issues start Service Portmap, nfsd exportfs Verify directory/var/lib/nfs/xtab showmount Observe the port number initiated
Ok. Each of the detailed items to talk about it: System requirements:
Crunch Is there a minimum hardware requirement for NFS? Oh. You are mistaken. The requirements here are actually "software requirements". What is needed is: In addition to the two kits that we have just mentioned, "Portmap and Nfs-utils" will need to exist, and your core version should be better than 2.2.xx. In addition, if you recompile the core, you must "choose" NFS support only. Now, if you're using the Linux distribution preset core at installation time, you don't have to worry too much, because the system already has the default support for NFS. So you can play the bottom. However, if you have recompiled the core and do not know how you compile it (e.g. hearsay, try something new. To compile your core, so do not notice the selection of this project), this time please come up with "Brother Bird's Linux private dish--basic study article" read it Again " Core compilation ". /etc/exports:
Well, after we've confirmed everything OK, we're really going to play with NFS. This thing is really very simple, as long as a file can be done. That is editor/etc/exports this file, please note that if this file does not exist, please set up yourself. And, don't write the file name wrong. The contents of this file are very simple, and we list his rules:
　

[Root@test root]# Vi/etc/exports [Directory to share] [Host name 1 or IP1 (parameter 1, parameter 2)] [Host Name 2 or IP2 (parameter 3, parameter 4)]

　
The rule above is this: [the directory to share] is primarily to be shared with [host name 1] and [host name 2], however, the permissions provided to the two are not the same, where the permissions given to the host name 1 are parameter 1 and parameter 2, and the Client permission to the host name 2 is parameter 3 and parameter 4. Well, then the "permission" that is the "parameters" of the main ones. RW: erasable permissions; RO: read-only permission; No_root_squash: Log on to an NFS host using a shared directory, and if it is root, then for the shared directory, he has root privileges. This item is "extremely unsafe" and is not recommended. Root_squash: When the user who is logged into the NFS host uses the shared directory if it is root, then the user's permissions will be compressed into anonymous users, and usually his UID and GID will become the identity of the nobody system account; All_squash: No matter login to NF S user identity, his identity will be compressed into anonymous users, usually the nobody. Anonuid: The previous UID set value for the anonymous user mentioned in *_squash, usually nobody, but you can set the value of the UID yourself. Of course, this UID will need to exist in your/etc/passwd. Anongid: Same as Anonuid, but become a group ID. Sync: Data synchronization writes to memory and hard disk; Async: The data is temporarily stored in memory rather than written directly to the hard disk. The approximate parameters are these few things. So let's assume a couple of examples: think of one: I'm going to share/tmp out for everyone, because this directory is the one that everyone can read and write, so I want to make it accessible to all people. Also, I'm going to let root write to the file that has root permissions. Well, you can write that.

[Root@test root]# Vi/etc/exports /tmp * (Rw,no_root_squash)

This way, no matter where it comes from (* universal character). It means everything OK. ) can use my/tmp directory. Please note that there is no spaces in the middle of that * (Rw,no_root_squash). and/tmp and * (Rw,no_root_squash) are spaces to separate. Pay special attention to the function of the No_root_squash. In this example, if you are the client side, and you are logged in as Root on your Linux host, then when you mount/tmp of my host, you will have "root" in the directory of the Mount. 』
Think about two: I'm going to expose a public directory/home/public, but only if you qualify my local domain network 192.168.0.0/24 this domain can read and write, and others can only reads:

[Root@test root]# Vi/etc/exports /tmp * (Rw,no_root_squash) /home/public 192.168.0.* (rw) * (RO) /home/public 192.168.0.0/24 (rw) * (RO)

Note that in the above example, the last two lines of formatting can be applied. So just write a line. The above example says that when my IP is 192.168.0.0/24 this segment, when I mount the server-side/home/public on the client side, I have permission to read and write for this directory I am mounting to, and if I am not within this network segment, then I can only read the data of this directory, that is, the read-only attribute.
Thinking three: I want to open a private directory/home/test to 192.168.0.100 this client-side machine to use, then I must write this:

[Root@test root]# Vi/etc/exports /tmp * (Rw,no_root_squash) /home/public 192.168.0.* (rw) * (RO) /home/test 192.168.0.100 (rw)

That's the end of the set. Moreover, only 192.168.0.100 this machine can access the directory of/home/test Oh.
Think four: I want to let the host of *.linux.org domain, login to my NFS host, can access/home/linux, but when they save data, I hope their UID and GID become 40 users of this identity:

[Root@test root]# 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)

Pay special attention to the function of the All_squash and Anonuid, Anongid. As a result, when test.linux.org is logged into this NFS host, and when/home/linux writes to the file, the owner and all groups of the file become the user of the identity of the/etc/passwd with the corresponding UID of 40. About Permission issues:
At any time, the issue of permissions needs to be taken into account. Let's take a look at the contents of the/etc/exports file just created:

[Root@test root]# 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 I log into this NFS (IP assumed 192.168.0.2) host in 192.168.0.100, and I have the ID of 192.168.0.100 as test, and I have test this account on this NFS, and if so, that Mody: Because 192.168.0.2 this NFS host's/tmp permission is-RWXRWXRWT, so I (test on 192.168.0.100 above) in/TMP has access permissions, and writes the file owner for test; in/h Ome/public, because I have read and write permission, so if the permissions on the/home/public directory are open to test, then I can read and write, and I write to the file owner is test. But in case/home/public has no permission to write to test this user, then I still have no way to write to the file. Please pay special attention to this. In/home/test, my permissions are in the same state as/home/public. You also need the/home/test for NFS hosts to have open access to test; it's a hassle in/home/linux. Because no matter what type of user you are, your identity will be turned into the uid=40 account. Therefore, the directory will need to the UID = 40 of the account name, modify his permissions to do.
So if I am in the 192.168.0.100 identity is test2, but 192.168.0.2 this NFS host but did not test2 this account, the situation will become what. I still can write in/tmp, but the file written by everyone becomes nobody, I can write in the/home/public, but also depending on the/home/public, but, anyway, my identity is turned into nobody is;/home/t EST has the same view as/home/public. Under/home/linux, my identity is changed to UID = 40 the user.
So what if I'm in the 192.168.0.100 as root. Root This account every system will have AH. Oh. What about permission? I can write in/tmp, and because of the No_root_squash parameters, changed the preset root_squash settings, so the files written in/tmp are root OH. My identity under the/home/public is still compressed into nobody. Because the preset attributes have root_squash in them. So, if/home/public has open write permission for nobody, then I can write, but the file owner becomes nobody. /home/test is the same as/home/public; in/home/linux case, my root identity is also compressed into the user of UID = 40.
After this permission is explained, you can understand it. Here is the most important place, if this pass, the bottom of the drum is no problem. ^_^ Start service Portmap, NFSD
OK, set OK also have no permissions after the problem (there is no problem, you can later in a good review and modify some.) And then again, it's natural to start him. How to start it. It's simple, just give him the OK down.

[Root@test root]#/etc/rc.d/init.d/portmap start<== start Portmap. [Root@test root]#/etc/rc.d/init.d/nfs start <== starting NFS

That Portmap doesn't need to be set at all. Just start him on the right. After startup, a SUNRPC service of Port 111 will appear. That's portmap. As for NFS, it will start at least two daemon. And then you start listening to the client side of the demand. After starting, please hurry into the/var/log/messages inside to see if it has been properly started.

[Root@test root]# Vi/var/log/messages Nov 15:04:45 Test Portmap:portmap startup succeeded Nov 15:04:53 Test nfs:starting NFS services:succeeded Nov 15:04:54 Test Nfs:rpc.rquotad startup succeeded Nov 15:04:54 Test Nfs:rpc.mountd startup succeeded Nov 15:04:54 Test NFS:RPC.NFSD startup succeeded

To normal appearance of the above words, it is the correct start Oh. Exportfs:
OK, so if we change the/etc/exports file, do we need to restart NFS? Oh, do not need, as long as the use of Exportfs again/etc/exports this file, and will be set to load again. Therefore, it is necessary to understand the use of Exportfs:

Grammar: [Root@test root]# Exportfs [-aruv] Parameter description: -A: All mount (or uninstall) the settings in the/etc/exports file -R: Re-mount the/etc/exports inside the set, in addition, also synchronized update/etc/exports and the contents of/var/lib/nfs/xtab. -U: Uninstalling a directory -V: In export, the shared directory is displayed on the screen. Example: [Root@test root]# EXPORTFS-RV <== All the new export once. Exporting 192.168.0.100:/home/test Exporting 192.168.0.*:/home/public Exporting *.linux.org:/home/linux Exporting *:/home/public Exporting *:/tmp Reexporting 192.168.0.100:/home/test to Kernel [Root@test root]# Exportfs-au <== all uninstalled.

Be familiar with the usage of this instruction. In this way, we can directly re export our records in the/etc/exports directory data. Inspection directory/var/lib/nfs/xtab
Well, how do you know how to share permissions for each directory after you have successfully shared your catalogs? Don't forget, because we have quite a lot of preset properties. Therefore, this time you need to check the contents of the directory you share. Take a look at/var/lib/nfs/xtab's file. He's kind of like this:

[Root@test root]# Vi/var/lib/nfs/xtab /home/test 192.168.0.100 (Rw,sync,wdelay,hide,secure,root_squash, No_all_squash,subtree_check,secure_locks,mapping=identity,anonuid=-2, ANONGID=-2)

See, No. This is the default NFS attribute of the/home/test this shared directory. In this attribute state there is a strange, that is anonuid=-2 this, how to have uid=-2 of it. Oh. In fact, it says the value of 65536-2, which is the UID of 65534. If you compare/etc/passwd, you'll find, wow. It turns out that's nobody. Showmount:
Showmount, as the name suggests, is to see if there is a command to mount. How to use it.

Grammar: [Root@test root]# showmount [-AE] hostname -A: Displays the current usage directory status attached to the host and Client on the screen -E: Displays the shared directory within the/etc/exports of the hostname machine. Example: [Root@test root]# showmount-e localhost Export list for localhost: /tmp * /home/linux *.linux.org /home/public (Everyone) /home/test 192.168.0.100

It's very simple. So, when you want to scan the NFS-shared directory that a host has provided, use SHOWMOUNT-E IP (or hostname). It's very convenient. Observe the activated port number:
Ok. Let's see how much port we started after we started NFS. Note that we have to start Portmap with NFS two scripts oh.

[Root@test root]# Netstat-utln Active Internet connections (only servers) Proto recv-q send-q Local address Foreign TCP 0 0 0.0.0.0:111 0.0.0.0:* LISTEN <== from Portmap TCP 0 0 0.0.0.0:817 0.0.0.0:* LISTEN <== from rpc.xxxx TCP 0 0 0.0.0.0:1266 0.0.0.0:* LISTEN <== from rpc.xxxx UDP 0 0 0.0.0.0:2049 0.0.0.0:* <== is Port of NFS UDP 0 0 0.0.0.0:814 0.0.0.0:* <== from rpc.xxxx UDP 0 0 0.0.0.0:1327 0.0.0.0:* <== from rpc.xxxx UDP 0 0 0.0.0.0:111 0.0.0.0:* <== from Portmap

Pay attention to see the above OH. A total of a lot of port oh. It's terrible. First notice that the Port that NFS itself opened is the 2049 port. That's the main port that NFS produces. Then the other rpc.xxxx's port comes from. NFS server as we mentioned earlier, he is a kind of RPC server, and NFS because of the provision of multiple program (such as Rpc.mountd, Rpc.rquotad, rpc.nfsd ...), so you need to start multiple port 。 And the port is "randomly generated", which means that port number is not fixed. Every Time restart NFS gets a different port number. So how do the client side know to connect to the port to call the required program? Oh. That is the function of the port number that SUNRPC (port 111) that Portmap service produces. The Client will first connect to the port of Sunrpc to know which port to call the required program. So, rpc.xxxx and the like daemon naturally don't need to have a fixed port number. Ok. As a result, Server-side settings are OK.
　
RPC server-related directives:
　
OK, now that we know this NFS is actually using RPC, then of course you know what each port in RPC is doing. This time, we can not do not know rpcinfo this command. Let's talk about the use of this instruction first.
　

Grammar: [Root@test root]# Rpcinfo [-P] hostname (ORIP) -P: Displays all port and program information. Example: [Root@test root]# rpcinfo-p test.linux.org program Vers Proto Port 100000 2 TCP Portmapper 100000 2 UDP Portmapper 100011 1 UDP 1014 Rquotad 100011 2 UDP 1014 Rquotad 100011 1 TCP 1017 Rquotad 100011 2 TCP 1017 Rquotad 100003 2 UDP 2049 NFS 100003 3 UDP 2049 NFS 100021 1 UDP 1339 Nlockmgr 100021 3 UDP 1339 Nlockmgr 100021 4 UDP 1339 Nlockmgr 100005 1 UDP 1340 MOUNTD 100005 1 TCP 1271 Mountd 100005 2 UDP 1340 MOUNTD 100005 2 TCP 1271 Mountd 100005 3 UDP 1340 MOUNTD 100005 3 TCP 1271 Mountd