ゴミ箱に空フォルダが1個。名前は delete-me-mountainduck。消そうとすると Permission denied、sudo で押すと Directory not empty。ACL を剥がしてもセーフモードでもリカバリーでも蘇る。これ、ファイルシステムが壊れてるんでしょうか。
違いました。ディスクは正常で、中身は本当に空です。これは SF_DATALESS という placeholder で、削除済みの Mountain Duck マウント（死んだ File Provider ドメイン）の幽霊を背負っている。だから実体を読みに行く操作（rm、xattr、rmdir）は、応答しない配信元を待って固まる。AI に2台相談して両方が詰んだのも、能力ではなくこの天井のせいでした。
先に、やることだけ書きます。
statかls -ldOe@でフラグを見る。0x40000000（SF_DATALESS）かdatalessが立っていたら深追いしない- First Aid はかけない。直すのはファイルシステムではないので
mvでゴミ箱の外へ逃がす。リネームは中を読まないので固まらない- 開発元（iterate.ch）にログを送り、正規の teardown を促す
この mv だけで、実害であるエラーダイアログは止まります。以下は、なぜこうなるのかを掘った記録です。同じ画面と睨み合っている人だけ読んでください。
なぜ普通の削除が全部はね返るのか
rm は Permission denied。lsof で掴んでいるプロセスを探しても、出てくるのは別の NAS の Time Machine SMB の警告だけで、本件とは無関係でした（NAS が2台あると、こういうノイズで地味に時間を取られます）。属性を見ると group:everyone deny delete の ACL。chmod -N で剥がすと、症状が Permission denied から Directory not empty に変わる。壁は崩したのに次の壁が出てくる、嫌な手応えでした。
findは空、rmdirは「空じゃない」。なぜ食い違うのか
拡張属性に com.apple.file-provider-domain-id。値は65バイト前後で、io.mountainduck.fileprovider/ ＋ UUID の長さです。この空フォルダには「どの死んだドメインの持ち物か」が刻印されている。そして xattr -cr をかけると Operation timed out。普通なら一瞬の処理が、触れた瞬間に止まる。
find -ls ではディレクトリ自身しか出ません（空に見える）。なのに rmdir は Directory not empty。ユーザーランドから見える状態と、カーネルが保持している状態が食い違っている。
腑に落ちたのは stat を見たときでした。リンク数2（サブディレクトリゼロ＝空）、フラグ 0x40000000 が SF_DATALESS。中身は手元になく、必要になったら取りに行く placeholder の印です。ディスクは空のまま正常で、壊れていたのはファイルシステムではない。カーネルが dataless と見なして、読むたびに配信元（削除済みの FTP ドメイン）へ「中身をよこせ」と要求し、相手が死んでいるからタイムアウトする。rmdir も xattr も rm も、全部この一つの理由で詰まっていました。
消すべきは空フォルダではなかった
配信元を黙らせればいい、と killall fileproviderd で落とすと、launchd が即再起動して死んだドメインをまた掴む。追いかけっこです。fileproviderd は Apple 純正なのでセーフモードでも動く。リカバリーモードまで行くと動かないので rm -rf が通る。消えた、と思って再起動したら、ゴミ箱に同じものが戻っていました。再生成の根は、ディスクのフォルダでもアプリでもなく、登録のほうにある。
名指しで消す道は、Appleがもう塞いでいた
昔は fileproviderctl domain list / domain remove で古いドメインを名指しで消せました。今のサブコマンドに list も remove も無い。最近の macOS で廃止されています。Apple の開発者フォーラムに「あの簡単だったコマンドを引っ込められた」と嘆くスレッドが立つくらいで、正規の道は閉じている。
fileproviderctl dump を読むと、現役マウントは4つ。それとは別に、どれにも対応しない孤児 UUID が4つ残っていました（768ec29e、8ada3002、db21c765、11ad78d8）。過去に消したブックマークの亡霊です。孤児の UUID フォルダだけを ~/Library/Application Support/FileProvider/ から退避して再起動、まだ蘇る。Mountain Duck を入れ直して再登録、まだ蘇る。再生成の根は fileproviderd の管理データそのものに残っていて、フォルダ移動では届かない場所でした。
サードパーティのクリーナーはないのか
孤児ドメインだけを外す汎用ツールは、存在しません。ドメイン登録は NSFileProviderManager.removeDomain でしか正規に操作できず、そのドメインを所有するプロバイダ（Mountain Duck）のコンテナ権限がないと呼べない。サンドボックスとコード署名の都合で、第三者アプリが他社のドメインを消すのは原理的に無理です。CleanMyMac 系のアンインストーラも結局 fileproviderctl domain remove を呼ぶ前提で、その remove が消えた今は同じ壁に当たる。同じ症状の OneDrive ユーザーが Apple サポートに「下位レイヤーで強制削除する手段はあるか」と問い合わせて、返答待ちのままのやり取りも見ました。
結局どう凌いだか
実体の削除は諦めました。本当に嫌だったのは残骸が1個あることより、ゴミ箱を空にするたびにエラーが出ることです。なら外へ動かせばいい。
|
1 2 |
mkdir -p ~/.fp-graveyard mv ~/.Trash/delete-me-mountainduck ~/.fp-graveyard/ |
中身は dataless の空フォルダなので rm は固まりますが、リネーム（移動）は中を読まないので固まらない。.fp-graveyard は先頭がドットなので Finder にも出ません。視界から消えて、エラーも止まりました。容量はもともと食っていない。
根本解決ではないです。孤児登録は残っています。きれいに消したいなら ~/Library/Application Support/FileProvider/ を丸ごと退避して全プロバイダを再有効化するフルリセットしかないけれど、iCloud から Synology まで全部の再同期を巻き込むので、空フォルダ1個のためにやるには重すぎると判断しました。
次に同じ目に遭ったときのために
半日と AI 2台を溶かして分かったのは、ゴミ箱の中身が「実体」とは限らない、ということでした。SF_DATALESS の placeholder は、ディスクが空でも死んだプロバイダの幽霊を背負っていて、その幽霊を黙らせない限り rm も sudo も ACL 剥がしもセーフモードもリカバリーも効かない。そして今の macOS には、孤児になったドメインをユーザーが成仏させる正規ツールがもう無い。
消せないものを半日かけて消そうとした後だと、つい考えてしまいます。OS が「あなたのもの」と言っているこのフォルダを、あなた自身の権限では消せない。これは、はたして正常な状態なんでしょうか。
コメント