server/user-documentation
10
3
Fork 8
Code Issues Pull requests 2 Projects Activity

get rid of superfluous spaces

Browse source
This commit is contained in:
Emmanuel Seyman 2025-10-22 23:49:07 +02:00
commit d7c7e18373
1 changed files with 13 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

26
modules/ROOT/pages/services/filesharing-nfs-installation.adoc
View file

@ -16,7 +16,7 @@ The objective of this guide is how to setup __NFS Server__ on a Fedora Server Ed
NFS is a Network service in Linux used to share the files and directories of the Server to users (clients) on the network. It allows clients to _mount_ a remote directory or complete filesystem over a network and interact with it much like local storage is accessed. It is the same principle as Map Drive in Windows Systems. One of it most used benefits is to store and access data on central location.
The NFS Protocol was first introduced by Sun Microsystem in 1984. The protocol has evolved from its origins. Over the years, new versions have been released, adding new features. Currently, NFS v4.2 is the current version. Perhaps most practically significant is the optional user identification as well as a virtual ROOT.
The NFS Protocol was first introduced by Sun Microsystem in 1984. The protocol has evolved from its origins. Over the years, new versions have been released, adding new features. Currently, NFS v4.2 is the current version. Perhaps most practically significant is the optional user identification as well as a virtual ROOT.
NFS protocol is not encrypted by default, and unlike Samba, unless you activate the optional feature it does not provide user authentication. Access to the server is restricted by the clients’ IP addresses or hostnames.
@ -54,7 +54,7 @@ Furthermore, it is a best practice is to use a global NFS root directory and bin
In accordance to the Filesystem Hierarchie Standard (FSH), using a /srv/nfs4 directory as the NFS root is a good choice.
Following Fedora Server storage rationale, a system administrator will create a logical volume and mount it to either `/srv` to create a Logical Volume as a pool for various services, or `/srv/nfs` to create a Logical Volume, probably thin provisioned, for each service. In case of systematic extensive utilization, a static LVM volume of fixed size is advisable. For occasional usage, a thin provisioned logical LVM volume might be the better choice.
Following Fedora Server storage rationale, a system administrator will create a logical volume and mount it to either `/srv` to create a Logical Volume as a pool for various services, or `/srv/nfs` to create a Logical Volume, probably thin provisioned, for each service. In case of systematic extensive utilization, a static LVM volume of fixed size is advisable. For occasional usage, a thin provisioned logical LVM volume might be the better choice.
In this guide we will demontrate the latter and create a thin provisioned LV for each service in /srv.
@ -73,7 +73,7 @@ As already stated, nfs does not provide user authentication. A common way is to
+
[source,]
----
[…]$ sudo adduser -c 'nfs pseudo user' -b /nonexisting -M -r -s /sbin/nologin nfs
[…]$ sudo adduser -c 'nfs pseudo user' -b /nonexisting -M -r -s /sbin/nologin nfs
----
3. *Create and mount the required Logical Volumes*
@ -120,20 +120,20 @@ Finallly mount the created filesystem.
4. *Create and configure the directories to share*
+
In a typical use case you may create a directory 'common' to widely share data and a directory 'project', in which a team member shares data located in the home directory with the team.
In a typical use case you may create a directory 'common' to widely share data and a directory 'project', in which a team member shares data located in the home directory with the team.
+
[source,]
----
[…]# sudo mkdir -p /srv/nfs/{common,project}
[…]# sudo chown -R nfs.nfs /srv/nfs/*
[…]# sudo mount --bind /home/USER/PROJECT /srv/nfs/project
[…]# sudo chown -R nfs.nfs /srv/nfs/*
[…]# sudo mount --bind /home/USER/PROJECT /srv/nfs/project
----
+
To make the bind mount(s) permanent, add the following entries to the /etc/fstab file:
+
[source,]
----
[…]# vi /etc/fstab
[…]# vi /etc/fstab
/home/USER/PROJECT /srv/nfs/PROJECT none bind 0 0
----
@ -152,7 +152,7 @@ The commented out lines describe the default built in configuration.
+
[source,]
----
[…]$ sudo vi /etc/nfs.conf
[…]$ sudo vi /etc/nfs.conf
/home/USER/PROJECT /srv/nfs/PROJECT none bind 0 0
----
@ -160,7 +160,7 @@ The commented out lines describe the default built in configuration.
1. *Firewall configuration*
+
NFS uses port 2049 which is blocked in a Fedora standard installation by defaut.
NFS uses port 2049 which is blocked in a Fedora standard installation by defaut.
+
[source,]
----
@ -176,7 +176,7 @@ NFS uses port 2049 which is blocked in a Fedora standard installation by defaut
[…]# systemctl status nfs-server
----
+
This starts the NFS server only, but not the NFS client. Therefore, the server can not mount file ressources provided by another server. If required, additionally execute at first _`systemctl enable nfs-client.target --now`_. For additional details you may look at _`man 7 nfs.systemd`_.
This starts the NFS server only, but not the NFS client. Therefore, the server can not mount file ressources provided by another server. If required, additionally execute at first _`systemctl enable nfs-client.target --now`_. For additional details you may look at _`man 7 nfs.systemd`_.
3. Check availabe NFS capabilities
+
@ -208,7 +208,7 @@ So the NFS server supports versions 3 and all version 4 capabilities.
//systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket
//systemctl restart nfs-server
//+
//(see https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/configuring-an-nfsv4-only-server_exporting-nfs-shares[Configuring an NFSv4-only server] )
//(see https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/configuring-an-nfsv4-only-server_exporting-nfs-shares[Configuring an NFSv4-only server] )
//
//See for some additional ideas:
//
@ -290,7 +290,7 @@ Allow both read and write requests / only read requests on a NFS volume.
sync/async::
Reply to requests only after the changes have been committed to stable storage (Default) / allow the NFS server to violate the NFS protocol and reply to requests before any changes made by that request have been committed to stable storage.
secure/insecure::
Require that requests originate on an Internet port less than IPPORT_RESERVED (1024). (Default) / accepts all ports. using the insecure option allows clients such as Mac OS X to connect on ports above 1024. This option is not otherwise "insecure".
Require that requests originate on an Internet port less than IPPORT_RESERVED (1024). (Default) / accepts all ports. using the insecure option allows clients such as Mac OS X to connect on ports above 1024. This option is not otherwise "insecure".
wdelay/no_wdelay:: Delay committing a write request to disc slightly if it suspects that another related write request may be in progress or may arrive soon. (Default)
This option has no effect if async is also set. The NFS server will normally delay committing a write request to disc slightly if it suspects that another related write request may be in progress or may arrive soon. This allows multiple write requests to be committed to disc with the one operation which can improve performance. If an NFS server received mainly small unrelated requests, this behaviour could actually reduce performance, so no_wdelay is available to turn it off.
subtree_check/no_subtree_check::
@ -416,7 +416,7 @@ On client side, try to mount an exported subdirectory:
[…]# mount 192.168.1.200:/nfsfileshare /mnt/nfsfileshare
----
Display the active mounts
Display the active mounts
[source,]
----
[…]# mount | grep nfs