Debian NFS (Network File System)

NFS (Network File System) est un protocole qui permet d’accéder à des fichiers via le réseau. Il est basé sur le protocole RPC (Remote Procedure Call). Les clients montent la partition de la machine distante comme si c’était un disque local.

Sur le serveur

Installation

Installation très simple comme toujours avec Debian:
# apt install nfs-kernel-server

...
Les paquets supplémentaires suivants seront installés : 
  nfs-common rpcbind
...

Les dépendances de nfs-kernel-server sont:

Depends: libblkid1 (>= 2.16), libc6 (>= 2.14), libcap2 (>= 1:2.10), libsqlite3-0 (>= 3.5.9), libtirpc1 (>= 0.2.4), libwrap0 (>= 7.6-4~), nfs-common (= 1:1.2.8-9), ucf, lsb-base (>= 1.3-9ubuntu3)

Vérification de l’installation

Exécuter rpcinfo pour confirmer que le serveur est lancé, et accepte les requêtes sur le port 2049 (UDP et TCP).
# rpcinfo -p | grep nfs

    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs

Vérifier que le système supporte effectivement NFS:
# cat /proc/filesystems | grep nfs

nodev	nfs
nodev	nfs4
nodev	nfsd

Si la commande ne renvoie rien, il se peut que le module NFS ne soit pas chargé, auquel cas, il faut le charger avec :
# modprobe nfs
Enfin, vérifions que portmap attend les instructions sur le port 111 :
# rpcinfo -p | grep portmap

    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper

Cette même vérification sera à faire sur le client.

Configuration du partage

Il faut maintenant indiquer au serveur les répertoires qui seront partagés, les machines qui y auront accès et les conditions de ce partage. Tous ces réglages se font par l’intermédiaire du fichier /etc/exports.
Sa structure est la suivante :
**/répertoire_partagé (options de partage) (options de partage)**

Désignation des hôtes destinataires

On indique ici l’adresse ip ou l’intervalle d’adresses ip des machines pouvant accéder au partage.
Pour spécifier un intervalle, on joue sur le masque de sous réseau (voir les outils de calculs type gip : http://ip2cidr.com).
Les jokers (classiquement * ou ?) sont à proscrire à l’intérieur d’une adresse ip.
Ainsi, pour désigner un réseau domestique complet :

192.168.0.0/255.255.255.0

ou

192.168.0.0/24

Les autres solutions pour désigner les machines autorisées sont : nom d’hôte (connus via /etc/hosts ou un DNS), groupes réseau NIS, un domaine ou un sous domaine précédé d’un joker.

Discontinuité dans le groupe d’adresses IP
  • Introduction :
    Si, dans l’ensemble des adresses IP définies par la notation CIDR 192.168.0.0/24 nous avons décidé que seule l’adresse IP 192.168.0.28 ne puisse PAS accéder au partage NFS, il nous faudra définir plusieurs groupes d’adresses IP.
    • Pour les adresses IP 192.168.0.0 à 192.168.0.27
      28 n’étant pas une puissance de 2, il ne sera pas possible de regrouper ces 28 adresses IP dans un unique groupe.
      Cherchons, parmi les puissances de 2, celle qui sera la plus grande mais qui restera tout de même inférieure ou égale à 28 :
      2¹=2, 2²=4, 2³=8, 2⁴=16, 2⁵=32 Oups! on a dépassé 28, alors on va prendre 16, c’est à dire 2 puissance 4.
      Il faudra donc 4 bits pour définir ce groupe d’adresses, et la notation CIDR pour ce groupe sera donc : 32-4=28.
      Voilà donc ce premier groupe de 16 adresses : 192.168.0.0 à 192.168.0.15 qu’on notera : 192.168.0.0/28
      Il nous reste encore le groupe d’adresses 192.168.0.16 à 192.168.0.27, donc 12 adresses.
      12 n’étant pas une puissance de 2, il ne sera pas possible de regrouper ces 12 adresses IP dans un unique groupe.
      Cherchons, parmi les puissances de 2, celle qui sera la plus grande mais qui restera tout de même inférieure ou égale à 12 :
      2¹=2, 2²=4, 2³=8, 2⁴=16 Oups! on a dépassé 12, alors on va prendre 8, c’est à dire 2 puissance 3.
      Il faudra donc 3 bits pour définir ce groupe d’adresses, et la notation CIDR pour cet groupe sera donc : 32-3=29.
      Voilà donc ce deuxième groupe de 8 adresses : 192.168.0.16 à 192.168.0.23 qu’on notera : 192.168.0.16/29
      Il nous reste encore le groupe d’adresses 192.168.0.24 à 192.168.0.27, donc 4 adresses.
      Pour ces 4 adresses, il est tout-à fait possible de créer un groupe d’adresses IP les regroupant toutes, car 2²=4.
      Il faudra donc 2 bits pour définir ce groupe d’adresses, et la notation CIDR pour ce groupe sera donc : 32-2=30.
      Voilà donc ce troisième groupe de 4 adresses : 192.168.0.24 à 192.168.0.27 qu’on notera : 192.168.0.24/30
    • Pour les adresses IP 192.168.0.29 à 192.168.0.255
      226 n’étant pas une puissance de 2, il ne sera pas possible de regrouper ces 226 adresses IP dans un unique groupe.
      De plus, comme le dernier octet de la première adresse n’est pas une puissance de 2, il nous sera impossible d’utiliser un masque qui pourrait permettre de définir un groupe d’adresses en notation CIDR.
      On va donc énumérer les premières adresses de ce deuxième groupe jusqu’à obtenir une adresse de départ utilisable avec un masque.
      192.168.0.29
      192.168.0.30
      192.168.0.31
      192.168.0.32 Ahhh! On y est : 2⁵=32 corresponds bien à une puissance de 2, on va maintenant pouvoir définir un groupe d’adresses.
      Le groupe d’adresses suivant débutera donc à l’adresse IP suivante, soit : 192.168.0.32
      Avec cette adresse, on constate que les 5 derniers bits sont à 0 (32 => 0010 0000)
      Le masque utilisable sera donc de 32-5=27 et le groupe d’adresses IP sera donc noté : 192.168.0.32/27
      Ce masque permet donc de regrouper 2⁵=32 adresses en notation CIDR.
      Ce groupe d’adresses comprendra donc les adresses IP 192.168.0.32 à 192.168.0.63
      Le groupe d’adresses suivant débutera donc à l’adresse IP suivante, soit : 192.168.0.64
      Avec cette adresse, on constate que les 6 derniers bits sont à 0 (64 => 0100 0000)
      Le masque utilisable sera donc de 32-6=26 et le groupe d’adresses IP sera donc noté : 192.168.0.64/26
      Ce masque permet donc de regrouper 2⁶=64 adresses en notation CIDR.
      Ce groupe d’adresses comprendra donc les adresses IP 192.168.0.64 à 192.168.0.127
      Le groupe d’adresses suivant débutera donc à l’adresse suivante, soit : 192.168.0.128
      Avec cette adresse, on constate que les 7 derniers bits sont à 0 (128 => 1000 0000)
      Le masque utilisable sera donc de 32-7=25, et le groupe d’adresses IP sera donc noté : 192.168.0.128/25
      Ce masque permet donc de regrouper 2⁷=128 adresses en notation CIDR.
      Ce groupe d’adresses comprendra donc les adresses 192.168.0.128 à 192.168.0.255

    • Conclusion :
      Pour que le répertoire “/home” soit exporté et accessible en lecture et écriture (rw)
      pour l’ensemble des adresses définies par 192.168.0.0/24 SAUF pour l’adresse 192.168.0.28,
       il faudra inscrire la ligne suivante dans le fichier de configuration /etc/exports.
/home 192.168.0.0/28(rw) 192.168.0.16/29(rw) 192.168.0.24/30(rw) 192.168.0.29(rw) 192.168.0.30(rw) 192.168.0.31(rw) 192.168.0.32/27(rw) 192.168.0.64/26(rw) 192.168.0.128/25(rw)
	Bon, mais c'est quand même pas très pratique à lire une ligne aussi longue,  
	 mais dans le fichier "/etc/exports" il est possible de scinder cette trop longue ligne en plusieurs en utilisant le caractère "\".
/home                                                        \
192.168.0.0/28(rw)  192.168.0.16/29(rw) 192.168.0.24/30(rw)  \
192.168.0.29(rw)    192.168.0.30(rw)    192.168.0.31(rw)     \
192.168.0.32/27(rw) 192.168.0.64/26(rw) 192.168.0.128/25(rw)

Les options de partage classiques

Les options pas défaut sont en majuscule.

  • rw/RO
    Lecture & écriture / Lecture uniquement

  • SYNC/async (doit être spécifié, sinon warning de la part de exportfs)
    async permet au serveur NFS de passer outre le protocole NFS et de répondre aux requêtes avant que les changements effectués par une requête antérieure aient été appliqués. Utilisable raisonnablement en combinaison avec ro.

  • NO_SUBTREE_CHECK/subtree_check (doit être spécifié, sinon warning)
    Distinction subtile, retenir que : :Dans le cas du partage d’un répertoire de type /home, où beaucoup de fichiers peuvent être renommés, préférer no_subtree_check. :Pour un répertoire principalement ro, ou peu de fichiers sont renommés (par exemple /usr ou /var), préférer subtree_check.

  • fsid=0 ou fsid=root
    nfs4 utilise un pseudo système de fichiers. Il faut donc indiquer le répertoire qui en sera la racine, grâce à l’option fsid=0. Désormais, le montage de cette “racine” en nfs4 monte le répertoire ainsi désigné. Si l’on souhaite conserver la compatibilité avec les versions antérieures, il suffit de désigner la racine du serveur comme racine du pseudo système de fichiers en indiquant par exemple :

/ *(ro,async,no_subtree_check,fsdid=0)

Options de mapping

Attention, il s’agit d’un point délicat : l’UID de l’utilisateur de la machine cliente est utilisé sur le serveur. Aussi, pour créer un partage respectueux, il faut qu’il y ait correspondance exacte des UIDs/GIDs des utilisateurs/groupes entre le serveur et les clients. Pour contourner cette limitation, des options de mapping sont donc disponibles.

Par défaut, les utilisateurs mappés reçoivent l’uid/gid 65534. On peut écraser ces valeurs grâce aux options anonuid et anongid.

  • ROOT_SQUASH/no_root_squash : root_squash mappe root en utilisateur anonyme.
  • all_squash/NO_ALL_SQUASH : mappe tous les utilisateurs en utilisateur anonyme.

On peut résoudre le problème plus proprement en mettant en place un service d’annuaire typiquement NIS, basé lui aussi sur RPC, ou LDAP.

Les informations se trouvant sur une ligne sont les suivantes :

  • dossier partagé : chemin menant au dossier partagé.
  • hôte : indique quel est l’hôte qui peut accéder à ce partage, l’hôte peut être défini de plusieurs manières :
    • une IP : on indique simplement l’adresse IP de la machine pouvant accéder à ce partage.
    • un nom d’hôte : on indique le nom complet de l’hôte (pour peu qu’il soit connu du système au travers d’un DNS ou du fichier ‘‘hosts’’).
    • un nom de groupe réseau NIS (NIS netgroup) qui s’indique sous la forme ‘’@''.
    • un domaine avec un joker qui indique les machines d’un domaine ou sous-domaine; par exemple : ‘‘*.ubuntu-fr.org’’.
    • un intervalle d’IP avec le masque de sous-réseau; par exemple : ‘‘192.168.0.0/24’’ ou ‘‘192.168.0.*’’
  • options : indique les options de partage; nous n’allons pas parcourir toutes les options ensemble mais uniquement les plus importantes.
    • rw : permet la lecture et l’écriture sur un partage pour l’hôte défini (par défaut, les partages sont en mode ‘‘ro’’; c’est-à-dire en lecture seule).
    • async : permet au serveur NFS de violer le protocole NFS et de répondre aux requêtes avant que les changements effectués par la requête aient été appliqués sur l’unité de stockage. Cette option améliore les performances mais a un coût au niveau de l’intégrité des données (données corrompues ou perdues) en cas de redémarrage non-propre (par exemple en cas de crash système).
    • sync : est le contraire de ‘‘async’’. Le serveur NFS respecte le protocole NFS.
    • root_squash : force le //mapping// de l’utilisateur ‘‘root’’ vers l’utilisateur anonyme (option par défaut).
    • no_root_squash : n’effectue pas de //mapping// pour l’utilisateur ‘‘root’’.
    • all_squash : force le //mapping// de tous les utilisateurs vers l’utilisateur anonyme.
    • anonuid : indique au serveur NFS l’UID de l’utilisateur anonyme (considéré comme tel dans les précédentes options de //mapping//).
    • anongid : indique au serveur NFS le GID de l’utilisateur anonyme (considéré comme tel dans les précédentes options de //mapping//).
    • subtree_check : Si un sous-répertoire dans un système de fichiers est partagé, mais que le système de fichiers ne l’est pas, alors chaque fois qu’une requête NFS arrive, le serveur doit non seulement vérifier que le fichier accédé est dans le système de fichiers approprié (ce qui est facile), mais aussi qu’il est dans l’arborescence partagée (ce qui est plus compliqué). Cette vérification s’appelle subtree_check.
    • no_subtree_check : Cette option neutralise la vérification de sous-répertoires, ce qui a des subtiles implications au niveau de la sécurité, mais peut améliorer la fiabilité dans certains cas.

Exemples

/data 192.168.0.25(rw,sync,no_subtree_check) 192.168.0.33(ro,async,no_subtree_check)
/home 192.168.0.0/24(ro,async,no_subtree_check,fsid=0)
/home/pour_root 192.168.0.55(rw,sync,no_subtree_check,no_root_squash)

Redémarrage

# service nfs-kernel-server restart

ou

# /etc/init.d/nfs-kernel-server restart

Sécurisation

Le protocole RPC n’a pas la réputation d’être bien sécurisé, mais la version 4 de NFS entend corriger ce problème, elle est donc à privilégier. Il est déconseillé d’effectuer un partage NFS via internet, ou bien dans ce cas, opter pour un tunnel crypté.

  • S’assurer que les partages sont réservés à certaines IP dans /etc/exports
  • S’appuyer sur rpcbind (/etc/hosts.deny et /etc/hosts.allow) pour sécuriser l’accès au serveur NFS
  • Configurer convenablement iptables

rpcbind

Exemple de configuration (Tout le monde est interdit, puis le LAN est autorisé):
# nano /etc/hosts.deny

 rpcbind mountd nfsd statd lockd rquotad : ALL

# nano /etc/hosts.allow

...
 rpcbind mountd nfsd statd lockd rquotad: 10.11.12.

iptables

https://wiki.debian.org/SecuringNFS Source

Par défaut, les différents services NFS (lockd, statd, mountd, etc.) demandent des assignations de ports aléatoires à partir du portmapper (portmap/rpcbind), ce qui signifie que la plupart des administrateurs doivent ouvrir une gamme de ports dans leur base de règles de pare-feu pour que NFS fonctionne.

# rpcinfo -p | grep nlockmgr

    100005    1   udp  53978  mountd
    100005    1   tcp  41663  mountd
    100005    2   udp  59420  mountd
    100005    2   tcp  51826  mountd
    100005    3   udp  43855  mountd
    100005    3   tcp  42371  mountd

# /etc/init.d/nfs-kernel-server restart

# rpcinfo -p | grep mountd

    100005    1   udp  43892  mountd
    100005    1   tcp  55590  mountd
    100005    2   udp  44020  mountd
    100005    2   tcp  43086  mountd
    100005    3   udp  33108  mountd
    100005    3   tcp  57843  mountd

Il va donc falloir fixer les ports de ces services afin de créer les règles iptables.

# nano /etc/default/nfs-common

...
STATDOPTS="--port 32765 --outgoing-port 32766"
...

# nano /etc/default/nfs-kernel-server

...
RPCMOUNTDOPTS="-p 32767"
...

# nano /etc/default/quota

...
RPCRQUOTADOPTS="-p 32769"
...

# sysctl --system
# /etc/init.d/nfs-kernel-server restart

Nous pouvons maintenant fixer nos règles iptables:

iptables -A INPUT -s 10.11.12.0/24 -p tcp -m multiport --ports 111,2049,32764:32769 -j ACCEPT
iptables -A INPUT -s 10.11.12.0/24 -p udp -m multiport --ports 111,2049,32764:32769 -j ACCEPT

Sur le client

Installation

Installer le paquet nfs-common avec son gestionnaire de paquets habituel, par exemple :

# apt-get install nfs-common

Vérification de l’installation

Portmap doit attendre les instructions sur le port 111:

# rpcinfo -p | grep portmap
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper

Montage du répertoire distant

Les options de montage communes à tous les systèmes de fichiers

Pour mémoire, le raccourci “defaults” désigne l’ensemble des options suivantes : rw, suid, dev, exec, auto, nouser, et async.

Parmi toutes les autres options disponibles, les suivantes sont intéressantes :

  • “_netdev” indique que le système de fichiers se trouve sur un périphérique qui nécessite un accès réseau. Cela permet d’éviter d’essayer de le monter si la connexion réseau n’est pas établie.

  • AUTO/noauto monte (ou pas) le système de fichier à l’appel de “mount -a”, c’est à dire lors du boot.

Les options de montage spécifiques à NFS

Lorsq’un montage se fait pour un système de fichiers de type NFS, une série d’options spécifiques est alors disponible. Voici les plus utiles :

  • HARD/soft L’option hard spécifie au client d’attendre le retour du serveur dans le cas où celui-ci crasherait. L’utilisateur ne peut terminer l’attente, à moins d’avoir sélectionné l’option INTR. Dans une situation identique, l’option soft renvoie une erreur au programme appelant, au bout d’une durée d’attente à fixer grâce à l’option timeo.

  • INTR/nointr Intr permet d’interrompre les requêtes NFS si le serveur ne répond pas. Accompagne l’option HARD.

Syntaxe

On peut utiliser :

  • la commande mount :

# mount -t nfs4 -o <options> <ip_serveur>:<rep_serveur> <point_montage_local>

  • une entrée dans /etc/fstab

<ip du serveur>:/répertoire_partagé /point_de_montage nfs4 <options> 0 0

Exemples

Avec mount, montage de la “racine” nfs4 désigné au deuxième exemple de 1.3.4.

# mount -t nfs4 -o ro 192.168.0.11:/ /tous_les_homes

/etc/fstab :

...
192.168.0.11:/data	/home/serveur_nfs	nfs	_netdev,nodev,noexec	0	0
...

Sources

NFS - Les partages

Comment fournir des partages réseau NFS à des clients spécifiques

Avec NFS, nous pouvons exporter des répertoires spécifiques d’un système de fichiers sur le réseau vers d’autres clients, ce qui nous permet de partager divers fichiers sur le réseau. Il est important de le configurer correctement et de le sécuriser autant que possible afin que seuls les clients requis aient accès au partage NFS, sinon tout le monde pourra le monter et accéder aux données.

Pour ce faire, nous allons utiliser le fichier /etc/exports sur le serveur NFS et verrouiller les partages pour qu’ils ne soient accessibles que par des adresses IP spécifiques.

Si vous souhaitez savoir comment fonctionnent les différentes versions de NFS, consultez nos tests de performances NFS

Exemple d’environnement

Voici une liste de nos serveurs avec lesquels nous allons tester.

  • Client NFS: 192.168.0.28 - Ce client Linux monte un répertoire à partir du serveur NFS.
  • Serveur NFS: 192.168.0.45 - Ce serveur Linux servira un répertoire sur NFS.

Configuration NFS

Le serveur qui a les données à partager agira comme le serveur NFS et a besoin du paquet nfs-utils installé.

Nous allons également créer le répertoire sur le serveur NFS que nous allons partager via NFS. Dans cet exemple, il s’agira de /srv/nfs, mais cela peut être ailleurs.

mkdir /srv/nfs

Les points de montage du serveur NFS sont configurés avec le fichier /etc/exports. Ce fichier répertorie les répertoires accessibles via NFS. Vous pouvez également créer des fichiers de configuration dans le répertoire /etc/exports.d/, à condition qu’ils portent l’extension .exports.

Vous trouverez ci-dessous un exemple de configuration NFS dans le fichier /etc/exports.

cat /etc/exports

/srv/nfs 192.168.0.28 (rw, async)

Comme indiqué, nous affirmons que le répertoire /srv/nfs est disponible uniquement pour l’adresse IP 192.168.0.28. Par conséquent, seul le système possédant cette adresse IP pourra accéder au répertoire et le monter. Les noms d’hôte peuvent également être utilisés à la place des adresses IP.

Il est important de noter qu’il n’ya pas d’espace entre l’adresse IP et les options (rw, async), s’il y avait un espace, alors l’adresse IP aurait des options par défaut et le (rw, async) s’appliquerait à tout autre client qui tente d’accéder au partage NFS, ce qui donnerait essentiellement un accès en lecture/écriture à quiconque.

Après toute modification apportée au fichier /etc/exports, nous devons utiliser la commande exportfs pour mettre à jour le tableau des systèmes de fichiers NFS exportés.

exportfs -arv

L’indicateur -a exporte tous les répertoires, l’indicateur -r réexporte tous les répertoires et supprime les anciennes entrées, tandis que l’indicateur -v fournit des informations détaillées et génère toutes les exportations NFS.

Monter le partage NFS

Maintenant que nous avons préparé le partage NFS, seul 192.168.0.28 devrait pouvoir le monter, testons-le. Le système nfs-utils doit également être installé sur les systèmes client pour pouvoir monter NFS.

Tout d’abord sur le client, nous pouvons utiliser la commande showmount pour afficher une liste des montages exportés sur le serveur NFS.

showmount -e 192.168.0.45

Liste d’exportation pour 192.168.0.45: /srv/nfs 192.168.0.28

Nous pouvons essayer de monter ceci avec NFS avec la commande mount, l’espace libre dans le montage devrait alors apparaître avec la commande df.

# mount -t nfs 192.168.0.45:/srv/nfs /mnt
# df -h
Filesystem              Size  Used Avail Use% Mounted on
/dev/sda3                18G  4.3G   14G  25% /
devtmpfs                905M     0  905M   0% /dev
tmpfs                   914M   80K  914M   1% /dev/shm
tmpfs                   914M  8.9M  905M   1% /run
tmpfs                   914M     0  914M   0% /sys/fs/cgroup
/dev/sda1               297M  148M  150M  50% /boot
192.168.0.45:/srv/nfs   18G  4.3G   14G  25% /mnt

Ce montage n’est pas persistant. Si nous procédons à un redémarrage du système client, celui-ci ne sera pas monté automatiquement. Pour ce faire, nous pouvons ajouter les éléments suivants dans le fichier /etc/fstab du serveur client.

192.168.0.45:/srv/nfs     /mnt    nfs rw,async   0       0

Après avoir enregistré vos modifications dans ce fichier, vous pouvez d’abord démonter /mnt avec umount /mnt, puis exécuter mount -a, qui tentera de monter tout ce qui n’a pas déjà été monté dans /etc/fstab. Ceci devrait monter 192.168.0.45:/srv/nfs vers /mnt, ce qui se produira automatiquement au redémarrage.

Si un autre système que 192.168.0.28 tente de monter ceci, il recevra l’erreur ci-dessous après l’échec du montage.

mount.nfs: access denied by server while mounting 192.168.0.45:/srv/nfs

Notez que cela ne fait que limiter les clients par adresse IP en fonction de la configuration dans le fichier /etc/exports sur le serveur NFS. Aucune authentification n’est effectuée, nous pouvons donc utiliser les exportations NFS activées par Kerberos. . Kerberos peut également fournir un chiffrement car, par défaut, tout contenu transféré via NFS sera envoyé en texte clair non sécurisé.

Sommaire

Comme indiqué en spécifiant les adresses IP des clients autorisés dans le fichier de configuration NFS /etc/exports, nous pouvons limiter l’accès à ces clients et refuser tous les autres accès, en bloquant essentiellement l’accès aux partages de fichiers. Pour vous protéger contre une configuration incorrecte des exportations, le pare-feu pourrait également être modifié pour autoriser uniquement le trafic NFS provenant de systèmes clients spécifiques nécessitant un accès au serveur NFS. Pour fournir une authentification et un cryptage, nous devrions envisager d’implémenter Kerberos.

Comment fournir des partages NFS pour une collaboration de groupe

Auparavant, nous avions expliqué comment fournir des partages NFS à des clients spécifiques . Nous allons ici développer et expliquer comment un partage NFS peut être partagé avec les membres d’un groupe à des fins de collaboration.

Cela se fera principalement avec l’utilisation de set group ID (Set GID), car tous les fichiers et répertoires créés dans le partage de groupe seront automatiquement définis avec le même propriétaire que le partage lui-même.

Exemple d’environnement

Voici une liste de nos serveurs avec lesquels nous allons tester, les deux exécutant CentOS 7.

  • Client NFS: 192.168.0.28 - Ce client Linux monte un répertoire à partir du serveur NFS.
  • Serveur NFS: 192.168.0.45 - Ce serveur Linux servira un répertoire sur NFS.

Configuration du serveur NFS

Le paquet nfs-utils doit également être installé sur la machine client, car il est requis pour monter un partage NFS.

Nous allons également créer le répertoire sur le serveur NFS que nous allons partager via NFS. Dans cet exemple, il s’agira de /srv/nfs, mais cela peut être ailleurs.

mkdir /srv/nfs

Les points de montage du serveur NFS sont configurés avec le fichier /etc/exports. Ce fichier répertorie les répertoires accessibles via NFS. Vous pouvez également créer des fichiers de configuration dans le répertoire /etc/exports.d/, à condition qu’ils portent l’extension .exports.

Vous trouverez ci-dessous un exemple de configuration NFS dans le fichier /etc/exports.

cat /etc/exports

/srv/nfs 192.168.0.0/24(rw,sync,no_subtree_check,no_root_squash)

Après toute modification apportée au fichier /etc/exports, nous devons utiliser la commande exportfs pour mettre à jour le tableau des systèmes de fichiers NFS exportés.

exportfs -arv

L’indicateur -a exporte tous les répertoires, l’indicateur -r réexporte tous les répertoires et supprime les anciennes entrées, tandis que l’indicateur -v fournit des informations détaillées et génère toutes les exportations NFS.

Configurer le partage NFS avec SetGID

Maintenant que le serveur NFS est configuré avec le point de montage NFS de base /srv/nfs, nous devons configurer SetGID dans ce répertoire, comme indiqué ci-dessous.

chmod 2770 /srv/nfs

Cela a également défini les autorisations 770 sur le répertoire, de sorte que l’utilisateur racine et le groupe défini disposent d’autorisations complètes. Les 2 premiers permettent setgid.

Ensuite, nous créons un groupe appelé ‘partage’ et modifions le répertoire /srv/nfs afin que le propriétaire du groupe soit ce groupe ‘partage’. Nous spécifions également manuellement le GID qui sera utilisé pour le groupe en tant que 9999; il doit s’agir d’un numéro libre sur votre client et votre serveur. J’ai exécuté groupadd sur le client et sur le serveur, et créé un utilisateur test avec ce groupe.

groupadd -g 9999 partage
chgrp partage /srv/nfs

Nous pouvons confirmer que setgid est en place, comme indiqué ci-dessous, où le bit d’exécution pour les autorisations de groupe est une minuscule. Cela passera à une majuscule S si le groupe ne dispose pas de l’autorisation d’exécution et que seul setgid est en place.

ls -la

drwxrws—. 2 root partage 29 Aug 30 00:25 nfs

Désormais, tous les fichiers ou répertoires créés dans /srv/nfs se verront automatiquement attribuer le propriétaire du groupe ‘partage’, ce qui permettra essentiellement la collaboration de groupe, car tout utilisateur appartenant au groupe ‘partage’ pourra désormais accéder aux fichiers créés par d’autres utilisateurs du groupe. même groupe dans le répertoire /srv/nfs.

Test des groupes de partage NFS

Maintenant que le point de montage NFS est prêt, à partir du client, nous montons le partage NFS en tant qu’utilisateur root.

mount -t nfs 192.168.1.200:/srv/nfs /mnt

Désormais, si un utilisateur accède au répertoire /mnt et crée un fichier ou un répertoire, il appartiendra au groupe ‘partage’.

touch setgid-test

ls -la

-rw-r - r–. 1 test de racine 0 16 janvier 23:09 setgid-test

Par défaut, l’option ‘sec’ pour un montage NFS est ‘sys’, ce qui signifie que les numéros UID/GID sont mappés du client sur le serveur NFS.
Par conséquent, le groupe ‘partage’ doit être créé avec le même ID de groupe sur le client et le serveur pour que le groupe soit correctement transmis.
Par ailleurs, si vous utilisez un répertoire externe tel que IPA, le fait de définir la méthode sec sur krb5, par exemple, utilisera les valeurs UID/GID fournies par Kerberos plutôt que localement.

Sommaire

En utilisant SetGID sur notre répertoire exporté avec NFS, nous avons été en mesure de fournir un partage NFS accessible à plusieurs utilisateurs du même groupe.
Le partage est idéal pour la collaboration de groupe car tous les fichiers ou répertoires créés par un utilisateur appartenant au groupe défini sur le partage NFS seront automatiquement possédés par le même groupe, ce qui permettra à d’autres utilisateurs de ce groupe d’accéder également à ces contenus.

Les étapes importantes qui ont été effectuées ici ont été de changer la propriété du groupe du répertoire qui fait office de partage avec le groupe avec lequel nous souhaitons partager le contenu et de définir setgid sur ce même répertoire.