少し前まで、iMacが特定のネットワーク共有(「ワークシェア」と呼ばれます)上のファイルを処理していたときに、Xserveが失敗しました(電力損失)。この "Work Share"は現在スタックしています。 GUIには表示されません。ターミナルを使用してのみ検出できます。数日かけて電源を再投入した後でも、ls -a
はまだそこにあることを示していますが、シングルユーザーモードのrootとしても、コマンドを使用してマウントを解除することはできません。
そのボリューム(hdiutil、diskutil、umount)をアンマウントしようとするたびに、リソースがビジーであるというメッセージが表示され(何も使用していないため、リソースがビジーではない可能性があります)、エラーコード4915またはそれ以外の場合は単に失敗します。
問題は、real "Work Share"をマウントすると、内部で "Work Share-1"に名前が変更され、すべてのリンクと共有内のいくつかのファイルが壊れることです。誤った "Work Share"をアンマウントできない場合、そのコンピューターは再フォーマットしないと使用できなくなると想像します-そして、それに到達する必要はありません。
私は思いつく限りのことをすべて試しました-Sudoは今私を救うことができないようです。
このスタックしたボリュームをアンマウントする方法に関するアイデアはありますか?
/ Volumesにその名前のフォルダーが表示される以外に、リモート共有がまだマウントされていることをどのようにして知ることができますか? mount
またはdiskutil list
まだマウントされていると表示しますか?そうでない場合、得られるのはスタックマウントではなく、リモート共有が予期せずなくなった後に残されたマウントポイントディレクトリです。そのディレクトリにファイルがある場合、それらはローカルブートドライブに存在し、おそらくその共有で動作していたiMacで実行されているプロセスによって書き込まれたものです。
この場合は、残されたディレクトリとファイルを脇に移動するだけで修正できます。
Sudo mv /Volumes/Work\ Space ~/Desktop
...その後、リモート共有を再マウントします。
しかし、mount
がリモートマウントがまだマウントされていることを示している場合、まあ、そのような状態は再起動後も存続しないので、再起動したくないような状況でない限り、 iMacを再起動します。
それが機能しない場合は、最初にSudo umount -f YOURDEVICE
を試してください。このファイルがMacOSに存在する場合は、/etc/mtab
のエントリを削除してください。ファイルは通常自動的に更新されますが、破損している可能性があります。
編集できない場合は、rm -f
で削除してください。再作成する必要があります。
Mac OS 10.12.2 Sierraを使用していますが、上記は機能しませんでした。何がうまくいったか:
Sudo umount -Af -t nfs,smbfs
を実行しました/Volumes
ディレクトリ(cd /Volumes
)に変更し、残りのマウントポイントフォルダーを削除しました。マウントしたフォルダーの名前によってフォルダー名は異なりますが、私のフォルダーはAthena
と呼ばれていたため、Sudo rm -rf Athena/
でフォルダーが空であることを確認した後、ls Athena/
を実行しました。フォルダーを複数回マウントした場合、Athena-1/
、Athena-2/
などの名前が付いた残りのフォルダーが残っている可能性があるため、これらも削除する必要があります。また、Finderの環境設定で「Connected Servers」のチェックを外しました(これが効果があるかどうかはわかりません)。
Mac OS 10.13.6 High Sierraを使用していますが、以前の回答ではうまくいきませんでした。私の場合、/etc/fstab
を介して自動マウントを作成し、私の場合のフォルダーはPandora
と呼ばれ、root
が所有していました。私にとって何がうまくいったか:
vi /etc/fstab
を実行し、削除したいPandora
マウントの行を削除しました。Pandora
がroot
によって所有されておらず、代わりに通常のユーザーアカウントによって所有されていることに気付きました。rm -rf Pandora/
を使用してターミナルからフォルダを削除しました