"Identificador de arquivo NFS antigo" após a reinicialização

No nó do servidor, é possível acessar uma pasta exportada. No entanto, após a reinicialização (servidor e cliente), a pasta não pode mais ser acessada pelos clientes.

No servidor

# ls /data
Folder1
Forlder2

e o arquivo / etc / exportações contém

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

No cliente

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

Devo dizer que não houve nenhum problema com a pasta compartilhada do lado do cliente; no entanto, após a reinicialização (servidor e cliente), vejo esta mensagem.

Alguma maneira de consertar isso?

A ordem das reinicializações é importante. Reiniciar o servidor após os clientes pode resultar nessa situação. O identificador antigo do NFS indica que o cliente tem um arquivo aberto, mas o servidor não reconhece mais o identificador do arquivo. Em alguns casos, o NFS limpará suas estruturas de dados após um tempo limite. Em outros casos, você precisará limpar as estruturas de dados do NFS e reiniciar o NFS posteriormente. Onde essas estruturas estão localizadas depende um pouco do sistema operacional.

Tente reiniciar o NFS primeiro no servidor e depois nos clientes. Isso pode limpar os identificadores de arquivo.

Não é recomendável reiniciar servidores NFS com arquivos abertos de outros servidores. Isso é especialmente problemático se o arquivo aberto foi excluído no servidor. O servidor pode manter o arquivo aberto até ser reinicializado, mas a reinicialização removerá o identificador de arquivo na memória do lado do servidor. Em seguida, o cliente não poderá mais abrir o arquivo.

Determinar quais montagens foram usadas no servidor é difícil e não é confiável. A showmount -aopção pode mostrar algumas montagens ativas, mas pode não reportar todas elas. Os arquivos bloqueados são mais fáceis de identificar, mas exigem que o bloqueio seja ativado e depende do software do cliente para bloquear os arquivos.

Você pode usar lsofnos clientes para identificar os processos que têm arquivos abertos nas montagens.

Eu uso as opções harde intrmount nas minhas montagens NFS. A hardopção faz com que o IO seja repetido indefinidamente. A intropção permite que os processos sejam eliminados se eles estiverem aguardando a conclusão do NFS IO.

Experimente este script que escrevi:

#!/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

No servidor NFS, exporte UN e exporte novamente o sistema de arquivos:

exportfs -u nfs-server: / file_system exportfs nfs-server: / file_system

No cliente, monte o sistema de arquivos

mount -t nfs nfs-server: / filesystem / mount_point

verifique lsof do caminho específico e mate o respectivo pid. Em seguida, desmonte a partição e monte-a de volta.