web-dev-qa-db-ja.com

NFS：ネットワークの切断により、GnomeNautilusがハング/プログレスバーがジャンプする

/ etc/fstabを介してNFSv4エクスポートをマウントし、nautilusの共有フォルダーをマウントして使用します。

2つの問題があります：

  • 大きなファイル（約4 GB）をNFSサーバーにコピーすると、プログレスバーが急速に2 GBになり、基本的に移動が停止します。しかし、コピーはまだ進行中です-それはちょうどうまく表示されていません
  • Nfs共有をアンマウントせずにネットワークから切断すると、nautilusがフリーズします。

どうすればそれを回避できますか？

/etc/exportサーバー上

/export/share   192.168.0.0/24(rw,sync,insecure,no_subtree_check,anonuid=1000,anongid=1000)

/etc/fstabクライアント上：

server:/share   /mnt    nfs4    soft,tcp
linuxubuntugnomemountnfs
5
Alex

最初の問題も報告されていますが、答えはありません。コピーは、コピーが進行している間、システムの他の部分をロックする傾向があります（おそらく、ノームがGNOMEサービスとして広く使用しているためです）。

2番目のポイントで、私はこれがSO質問が非常に役立つことを発見しました： https://stackoverflow.com/q/40317/91808 。特にumount -f /mnt/nfs提案は、他に何もしなかったときにうまくいき、イライラする再起動から私を救いました。

1
andybuckley

自動マウントを使用します。アクセスされた/アクセスされなかったときに、共有を自動的にマウント/アンマウントします。プログレスバーの問題には影響しないと思いますが、フリーズは修正されるはずです。

設定方法の詳細については、 ここでの私の答え （具体的には、手順5〜7）を参照してください。

更新

共有ボリュームがホームディレクトリにリンクされている（または直接マウントされている）場合、ファイルマネージャがハングすることがわかりました。マウントポイントへのリンクを$HOMEのsubディレクトリに配置することで、フリーズが発生しなくなりました。

問題は、autofsがアクセスされるたびに、lsを含む共有をマウントすることです。そのため、nautilusを開いて、マウントを$ HOMEにリンクまたはマウントするたびに、マウントを試みてハングします。

したがって、私の現在の（ハングフリー）設定は次のとおりです。

  1. / mnt/shared/moviesにマウントされたNFS共有

  2. それは私の$ HOMEのサブディレクトリにリンクされています：

    $ ls $HOME | grep shared
shared
$ ls -l $HOME/shared
lrwxrwxrwx 1 terdon terdon 20 Feb 15  2012 movies -> /mnt/shared/movies

このように、ボリュームは、単純なls $HOME/sharedではなく、ls $HOMEを実行した場合にのみマウントされます。

最後に、-softオプションを使用していることを確認してください。

0
terdon