vagrantファイルの削除.nfs0000000000b869e300000001が表示されます

ファイルを削除すると、次のように表示されます。

$ ls
total 64
-rw-rw-r-- 1 502 17229 Sep 17 16:42 page_object_methods.rb
drwxrwxr-x 7 502   238 Sep 18 18:41 ../
-rw-rw-r-- 1 502 18437 Sep 18 18:41 new_page_object_methods.rb
-rw-r--r-- 1 502 16384 Sep 18 18:42 .nfs0000000000b869e300000001
drwxrwxr-x 5 502   170 Sep 21 13:48 ./
13:48:11 *vagrant* ubuntu-14 selenium_rspec_conversion

そしてそれを削除しようとすると：

$ rm .nfs0000000000b869e300000001
rm: cannot remove ‘.nfs0000000000b869e300000001’: Device or resource busy

これは何を示していますか？私は何をすべきか

プロセスで開いているファイルは削除できます。これが発生すると、ディレクトリエントリは削除されますが、ファイル自体（iノードとコンテンツ）は残ります。ファイルが実際に削除されるのは、リンクがなく、プロセスによって開かれていない場合のみです。

NFSはステートレスプロトコルです。操作は以前の操作とは無関係に実行できます。サーバーが再起動することも可能です。オンラインに戻ると、クライアントは以前と同じようにファイルにアクセスし続けます。これが機能するためには、ファイルを開くことによって取得される処理ではなく、ファイルを名前で指定する必要があります（サーバーは再起動時に忘れます）。

この2つをまとめると、クライアントがファイルを開いて削除するとどうなりますか？ファイルは名前を保持する必要があるため、ファイルを開いているクライアントは引き続きファイルにアクセスできます。ただし、ファイルが削除されると、その名前のファイルはその後存在しないことが予想されます。したがって、NFSサーバーは、開いているファイルの削除を名前変更に変換します。ファイルの名前が変更されます.nfs…（.nfsその後に文字と数字の文字列が続きます）。

これらのファイルを削除することはできません（試してみると、新しい.nfs…サフィックスが異なるサフィックスが表示されるだけです）。ファイルを開いているクライアントがファイルを閉じると、最終的にそれらは消えます。（ファイルを閉じる前にクライアントが消えた場合、サーバーが通知するまでしばらく時間がかかることがあります。）

別の質問のユーザー@mtakは次のことを提案します。

You could try runningフューザ/path/to/.nfsto check which process is using the .nfs file. – mtak May 2 '14 at 9:13

^^^^^うまくいきます^^^^^そして、問題のあるプロセスを終了して、ファイルハンドルを解放します。

例えば

$ rm -rf ~/Downloads
rm: cannot remove ‘/nfshome/x/Downloads’: Directory not empty
$ ls -alstr ~/Downloads
total 38864
  972 -rw-r--r--   1 x users   988438 Dec 20  2016 .nfs00000000018d307a00000369
31812 -rw-r--r--   1 x users 32503812 Dec 20  2016 .nfs00000000018d307f0000036b
  636 drwx--x--x 134 x y   647168 Aug 28 10:37 ..
  240 drwxr-xr-x   2 x y   241664 Aug 28 10:43 .
$ rm -rf ~/Downloads
rm: cannot remove ‘/na-homes/x/Downloads/.nfs00000000018d307a00000369’: Device or resource busy
rm: cannot remove ‘/na-homes/x/Downloads/.nfs00000000018d307f0000036b’: Device or resource busy

$ fuser /nfshome/x/Downloads/.nfs00000000018d307400000367
/nfshome/x/Downloads/.nfs00000000018d307400000367:  8231m
$ ps -elf |grep 8231
0 S x     1493 15153  0  80   0 - 28177 pipe_w 10:55 pts/39   00:00:00 grep --color=auto 8231
0 S x     8231  7660  0  99   - - 481464 poll_s Jul19 ?       00:06:01 /usr/libexec/tracker-extract
$ kill 8231
$ kill 8231 # kill twice to check first kill worked, . . 
            # escalate to kill -9 8231 if first kill didn't work, . . 
            # use sudo or root or other user to kill if ownership prevents kill working.
-bash: kill: (8231) - No such process
$ rm -rf ~/Downloads

$ ls -alstr ~/Downloads/
ls: cannot access /nfshome/x/Downloads/: No such file or directory

わーい！成功。

もちろんYMMV。ファイルを開いた状態で座っている別のプロセスかもしれません。

トラッカー抽出プロセスは、強制終了すると自動的に再開されました。

このトラッカー抽出物とは何ですか？（centos / redhatでこれを見ます）

/programming/26737900/tracker-extract-and-tracker-store-processes-consuming-huge-amount-of-ram

extra/tracker 1.2.3-1 (gnome)
    All-in-one indexer, search tool and metadata database

NFSは「ステートレス」であるため、ファイルを開くUNIXの方法をエミュレートして、開いているファイルハンドルを保持したままファイルを削除する方法が必要です。

NFSファイル操作により、チェーンが発生します。

open(); seek-last-off(); doit(); close();

これがNFSがサーバーの再起動後も生き残る理由です。

古いファイルを開いたクライアント上のプロセスが終了すると、ファイルは消えます。

正しく実装されたファイルサーバーは、1週間以上前のファイルをすべて削除するスクリプトを毎晩実行します。その理由は、そのようなファイルを保持している間にクライアントがリブートした場合、ファイルは永久に残るためです。

他のプロセスがファイルを使用している可能性があります（つまり、開いているファイルハンドルがあります）。ファイルを無視するlsofか、などを使用して、そのファイルが開いているプロセスを見つけてください（またはすべてを再起動してください！）。

同様の状況に直面しましたが、私の場合、自分のプログラムで作成されたファイルを削除することはできません。私のプログラムで作成されたディレクトリに存在していたので、私はこれを確信していました。そのプログラムをどこで、いつ実行したかはわかりませんでした。解決策：すべての端末を終了しました。再度ログインして、ファイルを削除しました。

PS私の答えは、指定したシーンリオに対してのみ有効です。