«Handle de fichier NFS périmé» après le redémarrage

Sur le nœud du serveur, il est possible d'accéder à un dossier exporté. Cependant, après les redémarrages (serveur et client), le dossier n'est plus accessible à partir des clients.

Sur le serveur

# ls /data
Folder1
Forlder2

et le fichier / etc / exports contient

/data 192.168.1.0/24(rw,no_subtree_check,async,no_root_squash)

Sur le client

# ls /data
ls: cannot access /data: Stale NFS file handle

Je dois dire qu'il n'y a pas eu de problème avec le dossier partagé côté client mais après les redémarrages (serveur et client), je vois ce message.

Une façon de résoudre ce problème?

L'ordre des redémarrages est important. Le redémarrage du serveur après les clients peut entraîner cette situation. Le descripteur NFS périmé indique que le client a un fichier ouvert, mais le serveur ne reconnaît plus le descripteur de fichier. Dans certains cas, NFS nettoiera ses structures de données après un délai d'expiration. Dans d'autres cas, vous devrez nettoyer vous-même les structures de données NFS et redémarrer NFS par la suite. L'endroit où ces structures sont situées dépendent quelque peu de l'O / S.

Essayez de redémarrer NFS d'abord sur le serveur, puis sur les clients. Cela peut effacer les descripteurs de fichiers.

Le redémarrage des serveurs NFS avec des fichiers ouverts à partir d'autres serveurs n'est pas recommandé. Cela est particulièrement problématique si le fichier ouvert a été supprimé sur le serveur. Le serveur peut garder le fichier ouvert jusqu'à ce qu'il soit redémarré, mais le redémarrage supprimera le descripteur de fichier en mémoire côté serveur. Le client ne pourra alors plus ouvrir le fichier.

Déterminer quels supports ont été utilisés à partir du serveur est difficile et peu fiable. L' showmount -aoption peut afficher certaines montures actives, mais peut ne pas toutes les signaler. Les fichiers verrouillés sont plus faciles à identifier, mais nécessitent le verrouillage pour être activé et s'appuie sur le logiciel client pour verrouiller les fichiers.

Vous pouvez utiliser lsofsur les clients pour identifier les processus qui ont des fichiers ouverts sur les supports.

J'utilise les options de montage hardet intrsur mes supports NFS. L' hardoption entraîne une nouvelle tentative d'E / S indéfiniment. L' introption permet de tuer les processus s'ils attendent la fin de NFS IO.

Essayez ce script que j'ai écrit:

#!/bin/bash
# Purpose:
# Detect Stale File handle and remove it
# Script created: July 29, 2015 by Birgit Ducarroz
# Last modification: --
#

# Detect Stale file handle and write output into a variable and then into a file
mounts=`df 2>&1 | grep 'Stale file handle' |awk '{print ""$2"" }' > NFS_stales.txt`
# Remove : ‘ and ’ characters from the output
sed -r -i 's/://' NFS_stales.txt && sed -r -i 's/‘//' NFS_stales.txt && sed -r -i 's/’//' NFS_stales.txt

# Not used: replace space by a new line
# stales=`cat NFS_stales.txt && sed -r -i ':a;N;$!ba;s/ /\n /g' NFS_stales.txt`

# read NFS_stales.txt output file line by line then unmount stale by stale.
#    IFS='' (or IFS=) prevents leading/trailing whitespace from being trimmed.
#    -r prevents backslash escapes from being interpreted.
#    || [[ -n $line ]] prevents the last line from being ignored if it doesn't end with a \n (since read returns a non-zero exit code when it encounters EOF).

while IFS='' read -r line || [[ -n "$line" ]]; do
    echo "Unmounting due to NFS Stale file handle: $line"
    umount -fl $line
done < "NFS_stales.txt"
#EOF

Sur le serveur NFS, exportez UN et réexportez le système de fichiers:

exportfs -u serveur-nfs: / système_fichiers exportfs-serveur-nfs: / système_fichiers

Sur le client, montez le système de fichiers

mount -t nfs nfs-server: / système de fichiers / mount_point

vérifier lsof du chemin spécifique et tuer le pid respectif. Démontez ensuite la partition et remontez-la.