Configuration du partage de fichier sur AlmaLinux : guide complet
Depuis mes premières expérimentations avec Linux à 15 ans, j’ai toujours privilégié les solutions robustes et éprouvées pour le partage de ressources en réseau. AlmaLinux, cette distribution née en 2021 suite à l’arrêt de CentOS classique, s’impose naturellement comme une plateforme fiable pour la configuration de services réseau. Je vous propose aujourd’hui d’analyser ensemble les différentes méthodes de partage de fichiers sur cette distribution, en privilégiant une approche technique et pragmatique.
Pour les pressés :
AlmaLinux permet de configurer efficacement des partages de fichiers réseau via le protocole NFS.
- Préparation système : installation de nfs-utils, configuration des adresses IP fixes et activation des services rpcbind nécessaires au fonctionnement NFS
- Configuration serveur : création du répertoire partagé avec permissions appropriées, édition du fichier /etc/exports pour déclarer les ressources et définir les options de sécurité
- Montage client : création des points de montage locaux, utilisation de la commande mount et automatisation via /etc/fstab avec les options adaptées
- Sécurisation : déploiement exclusif sur réseaux locaux de confiance, utilisation de sudo pour la traçabilité et authentification Kerberos pour environnements sensibles
Préparer l’environnement pour un partage réseau sécurisé
Avant toute manipulation, je m’assure systématiquement que mon infrastructure réseau répond aux prérequis fondamentaux. Pour mettre en place un système de partage NFS sur AlmaLinux, vous aurez besoin d’au moins deux machines : une serveur hébergeant les fichiers, et une cliente accédant aux ressources partagées. L’ANSSI recommande depuis 2019 dans ses guides officiels d’utiliser sudo plutôt que le compte root direct pour les opérations d’administration système.
La première étape consiste à identifier les adresses IP locales de vos machines. J’utilise personnellement la commande ifconfig dans le terminal, qui affiche l’adresse à la ligne « inet adr » dans la section « eth » pour une connexion filaire, ou « wlan » pour le Wi-Fi. Cette information se révèle indispensable pour la configuration ultérieure des autorisations d’accès. Je recommande fortement de fixer ces adresses IP, soit directement depuis l’interface de votre routeur, soit via les outils de configuration réseau d’AlmaLinux.
L’installation des paquets nécessaires s’effectue via la commande suivante que je tape en tant qu’administrateur : yum install nfs-utils. Cette commande installe l’ensemble des utilitaires NFS, protocole dont la compatibilité avec IPv6 fonctionne sur la plupart des systèmes modernes. Je vérifie toujours que les services rpcbind sont actifs avant de poursuivre, car ils constituent la base du fonctionnement de NFS.
| Composant | Fonction | Port utilisé |
|---|---|---|
| rpcbind | Mappage des services RPC | 111 TCP/UDP |
| nfsd | Serveur NFS principal | 2049 TCP/UDP |
| mountd | Gestion des montages | Variable |
| statd | Verrouillage de fichiers | Variable |
Configurer le serveur et déclarer les ressources partagées
La création du répertoire à partager représente une étape déterminante dans le processus. Je commence par exécuter mkdir -p /nfs/share, suivi de chmod 1777 /nfs/share pour attribuer les permissions appropriées. Le bit sticky (1) empêche les utilisateurs de supprimer des fichiers appartenant à d’autres, tandis que 777 autorise la lecture, l’écriture et l’exécution pour tous.
Le fichier /etc/exports constitue le cœur de la configuration NFS. J’y définis chaque partage selon une syntaxe précise : le chemin complet du dossier partagé, l’hôte autorisé, et les options de partage. Pour un réseau local 192.168.18.0/24, j’inscris par exemple : /nfs/share 192.168.18.0/24(rw,allsquash,anonuid=1000,anongid=1000,sync,nosubtree_check). Cette ligne autorise tous les ordinateurs de la plage IP à accéder en lecture-écriture au dossier.
Les options que j’utilise méritent quelques explications techniques. L’option allsquash force le mappage de tous les utilisateurs vers un utilisateur anonyme, identifié par anonuid et anongid. L’option sync garantit l’intégrité des données en respectant scrupuleusement le protocole NFS, contrairement à async qui améliore les performances mais présente des risques. Je privilégie nosubtree_check pour éviter les vérifications d’arborescence parfois sources de problèmes.
Après modification du fichier exports, je redémarre les services avec systemctl restart rpcbind. La commande exportfs -a active immédiatement les partages déclarés, tandis que showmount -e me permet de vérifier la liste des exports actifs. Si l’export ne s’affiche pas correctement, je n’hésite pas à relancer le service NFS complet via systemctl restart nfs-kernel-server, en m’assurant qu’aucun transfert n’est en cours.
Monter les partages sur les machines clientes
Du côté client, la procédure diffère légèrement mais reste accessible. Je crée d’abord les points de montage locaux avec mkdir /nfs/mount-pt1. La commande de montage manuel s’écrit : mount -t nfs 192.168.18.6 :/nfs/share /nfs/mount-pt1. Cette syntaxe précise le type de système de fichiers (nfs), l’adresse IP du serveur suivie du chemin distant, et enfin le point de montage local.
Pour automatiser le montage au démarrage, j’édite le fichier /etc/fstab. J’y ajoute une ligne respectant ce format : 192.168.18.6 :/nfs/share /nfs/mount-pt1 nfs defaults,user,auto,_netdev,bg 0 0. Les options méritent attention :
- defaults applique les paramètres standards
- user autorise les utilisateurs non-root à monter le partage
- auto monte automatiquement au démarrage
- _netdev indique que le système de fichiers requiert le réseau
- bg évite de bloquer le démarrage si le serveur est inaccessible
Sur les versions récentes d’AlmaLinux compatibles avec Ubuntu 22.04, j’ajoute l’option vers=4.0 pour forcer l’utilisation de NFSv4. Pour optimiser les performances sur un réseau Gigabit ethernet, j’ajoute rsize=16384,wsize=16384 qui améliore sensiblement la vitesse de transfert sur les gros fichiers. Sur un serveur moins puissant, vers=3,udp réduit la charge processeur en utilisant le protocole UDP.
Gérer la sécurité et résoudre les dysfonctionnements
La sécurité d’un partage NFS repose sur plusieurs principes que j’applique systématiquement. NFS, particulièrement avant la version 4, ne doit jamais être exposé sur Internet. Je le déploie uniquement sur des réseaux locaux de confiance, derrière un routeur NAT assurant une première couche de protection. Les pare-feu configurés sur les serveurs et clients doivent autoriser les ports NFS spécifiques sans filtrage excessif.
L’ANSSI souligne dans ses recommandations que l’utilisation de sudo améliore significativement la traçabilité des actions administratives. Chaque commande exécutée via sudo est enregistrée dans /var/log/auth.log, permettant de savoir précisément qui a effectué quelle opération et à quel moment. Cette approche évite le partage du mot de passe root entre plusieurs administrateurs.
Face à l’erreur « access denied by server while mounting », je vérifie d’abord les permissions du dossier partagé. Si le problème persiste, je rétrograde en NFSv3 en modifiant /etc/default/nfs-kernel-server côté serveur avec RPCNFSDCOUNT='8 --no-nfs-version 4', et en ajoutant vers=3 dans les options fstab côté client. Cette version utilise une authentification différente parfois plus compatible.
Pour les environnements plus complexes nécessitant une authentification Kerberos, comme avec un Shared Storage sur serveur Cloud, j’installe krb5-workstation et je copie les fichiers de configuration dans /etc. Cette méthode offre une sécurité renforcée en chiffrant les communications réseau et en authentifiant mutuellement serveur et client.
