正常にマウントされていたLinuxファイルサーバーからNFSv3をエクスポートしました。ファイルサーバーはハードウェアのメンテナンスのためにダウンする必要がありました。サーバーを再起動すると、Linuxクライアントはnfsエクスポートをマウントできなくなります。
サーバーまたはクライアントの構成は変更されていません。最初のマウントが失敗した後、ソフトウェアの更新を行い、クライアントを再起動しましたが、それは役に立ちませんでした。
[root@client ~]# showmount -e ark
Export list for ark:
/mnt/bigraid *
[root@client ~]# mount -t nfs ark:/mnt/bigraid raid
この時点でハングします。別の端末で...
[root@client ~]# dmesg | tail
[ 2526.676437] nfs: server ark not responding, timed out
[ 2529.183107] nfs: server ark not responding, timed out
[ 2531.689778] nfs: server ark not responding, timed out
[ 2538.196432] nfs: server ark not responding, timed out
[ 2540.703107] nfs: server ark not responding, timed out
[ 2543.209767] nfs: server ark not responding, timed out
[ 2545.716436] nfs: server ark not responding, timed out
[ 2548.223098] nfs: server ark not responding, timed out
[ 2550.729775] nfs: server ark not responding, timed out
[ 2557.236435] nfs: server ark not responding, timed out
... OK、でもshowmountでエクスポートを見ることができた...
[root@client ~]# ping ark
PING ark.homebase (10.10.10.2) 56(84) bytes of data.
64 bytes from ark.homebase (10.10.10.2): icmp_seq=1 ttl=64 time=0.067 ms
64 bytes from ark.homebase (10.10.10.2): icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from ark.homebase (10.10.10.2): icmp_seq=3 ttl=64 time=0.048 ms
64 bytes from ark.homebase (10.10.10.2): icmp_seq=4 ttl=64 time=0.042 ms
^C
--- ark.homebase ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
だから私はそれを取得しません。
サーバーはOpenSUSEを実行しています。ファイアウォールがオフになっている(オンになっていたわけではない)ことと、ネットワーク接続に問題がないようにした。
ark:/etc # cat exports
/mnt/bigraid *(rw,root_squash,insecure,no_subtree_check,sync)
編集:ここに使用中のRPCポートのリストがあります
ark:/etc/init.d # rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100005 1 udp 37599 mountd
100005 1 tcp 33880 mountd
100005 2 udp 37599 mountd
100005 2 tcp 33880 mountd
100005 3 udp 37599 mountd
100005 3 tcp 33880 mountd
100024 1 udp 49522 status
100024 1 tcp 41314 status
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 udp 51887 nlockmgr
100021 3 udp 51887 nlockmgr
100021 4 udp 51887 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 tcp 49804 nlockmgr
100021 3 tcp 49804 nlockmgr
100021 4 tcp 49804 nlockmgr
100000 2 udp 111 portmapper
編集2:tcpdump情報を入手した
(編集3:関連がない可能性があるため、tcpdump出力を削除しました。)
適切なNFSネゴシエーションがどのように見えるのか、私はまったく詳しくありません。データセグメントを確認する場合は、pcapファイルもダンプしました。 filedropper にあります
編集3:打つ可能性がある この問題
以下の@CIAのアドバイスに従って、これを行いました:
ark:/etc/init.d # ./nfsserver stop
Shutting down kernel based NFS server: nfsd statd mountd idmapd done
ark:/etc/init.d # ./portmap stop
Shutting down RPC portmap daemon done
ark:/etc/init.d # ./portmap start
Starting RPC portmap daemon done
ark:/etc/init.d # ./nfsserver start
Starting kernel based NFS server: idmapdexportfs: Warning: /mnt/bigraid does not support NFS export.
mountd statd nfsd sm-notify done
警告にもかかわらず、エクスポートはマウントできるようになりました。
そのため、NFSはポートマッパーの実行に依存しているので奇妙であり、特定のポートをRPCポートにマップできます。 (変ではないと思います。NFSがポートマッパーの前に起動している場合、NFSはプロセスの開始時にポートマッパーをチェックするため、要求をルーティングする方法を知りません。 NFSの前にポートマッパーが起動していない場合、NFSはポートをrpcにマップする方法を認識していません。
プロセスについての詳細なドキュメントは次のとおりです(CentOSの場合でも、関連性があります)。 http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s2-nfs-methodology- portmap.html
新しいエラーメッセージについては、マウントに使用しているボックスを再起動し、再度マウントして、エラーが再発するかどうかを確認します。
tcpdump -i $LAN_IF -n Host 10.10.10.2
失敗したNFSコンポーネントが表示されます。
与えられた回答からの解決策を要約するには、次の手順に従って、NFSを修正してNFSを正常にマウントするように指示しますボックスを再表示せずに.
クライアントサーバーでtcpdumpをNFSサーバーのIPアドレスに実行します(1.2.3.4と仮定)
tcpdump -i <replace-with-correct-INTERFACE_name -n Host 1.2.3.4
tcpdumpを実行し続け、NFSパスをマウントしてみてください。
nFSサーバーIPおよびallステップ3のtcpdump出力から取得したポートに対してtelnetを実行し、すべてのポート(この場合、ポートの下に2つだけ)にtelnetがあることを確認します。
telnet 1.2.3.4 880
telnet 1.2.3.4 2049
手順3で取得したポートのいずれにもtelnetがない場合は、それらのポートをnetwrokレベルで開く必要があります(ある場合はファイアウォール)。
まあ、私は同じエラーを取得するために使用しました。タイムアウトが発生する唯一の理由は、接続が適切に確立されていないためです。問題をさらに掘り下げて、ファイアウォールを確認したところ、NFS4サービスがブロックされました。
解決策:-以下のコマンドを使用してファイアウォール設定を構成し、NFS4サービスの横に*を追加して有効にします。
$ Sudo system-config-firewall-tui
ホストベースのファイアウォールがあり、NFSを使用している場合は、次の項目を確認してください。
http://wiki.debian.org/SecuringNFS
デーモンが使用しているポートを指定して、ランダムに割り当てられないようにすることができます。
私の場合、問題はサーバーの番号が付け直されていたにもかかわらず、クライアントが古いIPアドレスに接続しようとしていたことでした。
これは、NFSクライアントホストの問題を特定するのに役立ちました。
mount | grep addr=
次のTCPおよびクライアントのUDPポートがサーバー上のNFS共有にアクセスできるようにします。
NFS3 tcpの場合:111,662,875,892,2020,2049,32803
udp:111,2049,32769
NFS4の場合
tcp:111,2049 udp:111,2049
編集:上記のポートをNFSクライアントからTelnetしてみます