Shulou(Shulou.com)06/02 Report--

NFS, namely Network File system (Network File System), is a distributed file system protocol, which allows client hosts to access server-side files through the network just like the local file system, that is, remote server files can be directly mount (mounted) to the local file directory structure for access.

I. Software installation

The nfs-kernel-server package needs to be installed on the server side:

$sudo apt-get update $sudo apt-get install nfs-kernel-server

II. Server configuration

By default, if a shared directory is defined on the NFS server, all files under that directory and its subdirectories are accessible.

For security reasons, any file operations on the client that require superuser (that is, root user, UID=0 & GID=0) privileges are mapped by default to UID=65534 and GID=65534 users, that is, nobody:nogroup in Ubuntu systems.

For example, when a client uses root permission to create a file in a mounted shared directory, the owner and group of the file automatically becomes nobody:nogroup instead of root:root.

1. Create a shared directory on the server side

Sudo mkdir-p / var/nfs/gernel sudo mkdir-p / var/nfs/public sudo chown nobody:nogroup / var/nfs/gernel

two。 Modify the exports file

In order to make the shared files defined by the NFS server accessible to the specified client host, you need to add the corresponding records to the / etc/exports file on the server side.

The format of the file is as follows:

Directory Host (Options...) Host (Options) # comment for detailed syntax formats for / etc/exports files can be found in man exports.

File example:

/ var/nfs/gernel 192.168.56.0 take 24 (rw,insecure,sync,no_subtree_check) / var/nfs/public * (ro,insecure,sync,no_subtree_check) / home/starky 192.168.56.1 (rw,insecure,no_root_squash,sync,no_subtree_check)

The first record indicates that all hosts in the 192.168.56.0 rw 24 subnet can mount the var/nfs/gernel directory and have read and write (read / write) permissions

The second record indicates that all hosts can mount / var/nfs/public directory and have read-only (ro) permissions

The third record indicates that the host with client IP address 192.168.56.1 can mount the / home/starky directory and have read and write permissions, and any file operations with root permissions (UID=0, GID=0) are not mapped to nobody:nogroup by default, while the owner (group) is still root (no_root_squash).

Insecure option: allow remote access through any port

Sync option: forces the NFS server to write changes to the file to disk before responding to the request (emphasizing the consistency of the file content between the client and the server, but reducing the efficiency of file operation).

No_subtree_check option: disable subtree_check. Subtree_check is used to set up the server to check whether the file is still available in the specified directory structure when it receives a request (this option can cause errors in some cases: renaming a file while the file is opened on the client).

Third, the client mounts the shared directory

List the shared directories on the nfs server

$showmount-e 192.168.56.102Exports list on 192.168.56.102:/home/starky 192.168.56.1/var/nfs/public * / var/nfs/gernel 192.168.56.0

Create a mount point

Sudo mkdir-p / mnt/nfs/gernel sudo mkdir-p / mnt/nfs/public sudo mkdir-p / mnt/nfs/starky

Mount a remote directory

Sudo mount 192.168.56.102:/var/nfs/gernel / mnt/nfs/gernel sudo mount 192.168.56.102:/var/nfs/public / mnt/nfs/public sudo mount 192.168.56.102:/home/starky / mnt/nfs/starky

Permission test

As shown in the screenshot:

Nfs permission test

The permission setting of NFS is based on the permission management of the Linux file system, that is, after the client mounts the remote shared directory, it will treat them like a local disk directory and restrict access according to the owner (group) of the file and its corresponding permission settings.

The owner (group) of the gernel directory is nobody:nogroup (65534 65534), so although the directory has read and write permissions, non-root users cannot perform new operations. Root users are automatically mapped to nobody:nogroup because of the default security mechanism of NFS.

Since I have a user named starky on both the client side and the server side, and their UID:GID is 1000 home/starky 1000, the / server directory on the server side can be accessed directly by the client starky user. And because of the no_root_squash option, the owner of a file created by the sudo command is still root (instead of being mapped to nobody).

Of course, this can lead to some security problems, for example, if multiple clients have users with a UID (GID) of 1000 at the same time (regardless of the user name), these users will share file permissions in the server / home/starky directory.

Fourth, automatically mount the shared directory when the system starts

The editable / etc/fstab file makes the mount operation of mounting a shared directory a fixed configuration of the system (the mount command entered manually belongs to temporary mount, and restart will automatically unmount it), so that the remote file system can be mounted automatically after system restart. An example of the / etc/fstab file is as follows:

# filesystem mountpoint fstype flags dump fsck192.168.56.102:/var/nfs/gernel / mnt/nfs/gernel nfs rw,bg,intr,hard,nodev,nosuid 0 0192.168.56.102:/var/nfs/public / mnt/nfs/public nfs4 ro,bg,intr,soft,nodev,nosuid 0 0192.168.56.102:/home/starky / mnt/nfs/starky nfs rw,bg,intr,hard,nodev,nosuid 0 Appendix:

Appendix:

1. / Host format in etc/exports file

The format of / etc/exports file is: Directory Host (Options...) Host (Options) # comment

The Host entry is used to specify the hosts that can access the corresponding shared directory. The format can be divided into the following:

Single host

The Host entry can be one or more individual TCP/IP hostnames or IP addresses

Adminadmin.starky.net192.168.56.101

IP subnet

10.0.0.0/255.0.0.0 172.16.0.0/255.255.0.0192.168.56.0/24

TCP/IP domain

By using wildcards, you can specify all or part of the hosts in a particular domain

* .starky.net * craft.starky.net???.starky.net

NIS group

You can specify access to all hosts in a NIS group, using @ group

2. / Options in the etc/exports file

Options describe ro read-only permissions rw read-write permissions (default) rw= list specifies client hosts with write permissions through list, other hosts map UID 0 and GID 0 to anonuid and anongid (that is, nobody and nogroup in Ubuntu systems) no_root_squash allows file operations that require root permissions, there is security risk all_squash maps all UID and GID to their anonymous form Operations that specify client root permissions mainly for untrusted hosts anonuid= xxx need to be mapped to UID (default is 65534) anongid= xxx specify client root permissions operations need to be mapped to GID (default is 65534) insecure allows remote access through any port async server can respond to client write requests before writing to the hard disk wdelay synchronizes multiple client updates to files sec= flavor refers to Security Verification method for determining shared Directory Includes sys (UNIX authentication), dh (DES), krb5i, krb5p and none (anonymous access)

3. NFS mount option

Option describes that rw mounts the file system in read-write mode (rw also needs to be defined on the server side) ro mounts the file system in read-only mode bg if the mount fails (the server does not respond), continue to try and execute other mount requests hard in the background if the server does not respond, repeat the request until the server replies soft if the server does not respond, repeat the request and return an error after a certain period of time It does not block intr all the time and allows the user to interrupt the blocked file operation (and returns an error) nointr does not allow the user to interrupt the client's file operation request retrans= n in soft mode Specify the number of times to repeat the request before returning an error timeo= n set the time interval to repeat the request after the timeout (in 1 to 10 seconds) rsize= n set the read buffer size to n byteswsize= n set the write buffer size to n bytessec= flavor set the security verification method proto= proto set the transport protocol, NFSv4 must be TCP

4. NFS protocol discussion

Transport protocol

The original NFSv2 uses UDP protocol for performance reasons. Although NFS adds its own packet sequence reorganization and error checking functions, UDP and NFS do not have blocking control algorithms, so they lack sufficient performance in large-scale Internet environments.

NFSv3 provides a choice between UDP and TCP protocols. NFSv4 can only use the TCP protocol.

With the improvement of CPU, memory and other hardware devices and network transmission speed, it is no longer necessary to choose the UDP protocol because of the performance requirements.

State

NFSv2 and NFSv3 are stateless connections. Instead of tracking client mounts to the shared directory, the server uses "cookie" to record a successful mount. "cookie" is not deleted because the server is restarted and can be used to retain client connection information after the server hangs.

NFSv4 is a stateful connection, and both the client and the server maintain file operation records and file lock status. So the use of "cookie" is no longer needed.

File lock

Earlier versions of the NFS protocol (v2 & v3) did not know which files were being used by which hosts because they were stateless connections. However, the implementation of file lock needs to obtain status information. So file locks in early protocols are implemented independently of NFS.

NFSv4 integrates the implementation of file locks into the core protocol, which increases complexity, but also solves many of the problems in earlier versions.

However, in order to be compatible with clients using V2 and V3 protocols, separate locked and statd daemons are still required.

Safety related

The NFS protocol was originally designed with no concern for security. NFSv4 strengthens the security of the protocol by introducing support for more powerful security services and authentication.

Traditional NFS protocols mostly use AUTH_SYS authentication, based on UNIX user and group identification. In this way, the client only needs to send its own UID and GID and compare it with the contents of the / etc/passwd file on the server to determine what permissions it has.

So when multiple clients have users with the same UID, those users will have the same file permissions. Further, users with root privileges can switch to any UID login through the su command, and the server will give them permission for the corresponding UID.

To prevent the above problems, the server can choose to use a more robust authentication mechanism such as Kerberos with NFS PRCSEC_GSS.

Access control for NFS shared directories is based on the hostname or IP address defined in the / etc/exports file. However, it is easy for clients to fake their identity and IP address, which can also lead to some security problems.

NFSv4 only uses TCP as its transport protocol, and usually only opens port 2049 for data transmission. When configuring a firewall, in addition to relaxing the restriction of port 2049, we should always pay attention to the source and destination addresses of data transmission.

5. Mount the shared directory on the Windows system

The win10 system cannot mount the NFS shared directory by default. You need to enter the Control Panel-programs-programs and functions-enable or disable the Windows function, and check the NFS service.

Enable the nfs service

You can then mount the shared directory using the mount command.

Mount command mounts a shared directory

It's just that the Windows system does not use user management like Linux, resulting in mounted shared directories that can only be read but not written.

Unable to write to file

The workaround is to create two new DWORD values in the registry to serve as UID and GID for anonymous users.

The mount options under the default parameters are-2 for both UID and GID:

Default mount option

You can enter the Registry Editor (regedit), navigate to HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ ClientForNFS\ CurrentVersion\ Default, create two new DWORD (32-bit) values named AnonymousUid and AnonymousGid, and change them to the numbers you need (I have changed them to 0, which corresponds to root users in the Linux system. If you need to change it to a number other than 0, please convert it to 16 bits first.

At this point, the mount option becomes:

Change UID and GID

If the change does not take effect, restart the computer.

references

UNIX and Linux System Administration Handbook, 4th Edition

How to Mount an NFS Share Using a Windows 10 Machine

The above is the whole content of this article, I hope it will be helpful to your study, and I also hope that you will support it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.