コンテナデータ、サンドボックスと署名 ID
要点
~/Library/Containers/ と ~/Library/Group Containers/ のデータは、サンドボックスアプリのものです。「ショートカット」（シンボリックリンク）で外部ドライブへ移すと読めなくなります。以前の AppPorts は再署名でこの制約を回避していましたが、macOS 27 でアプリが開けなくなったり、ログイン状態が失われたりする可能性があります。
1.9.0 以降はコンテナデータにマウント移行を使い、署名を 1 バイトも変更しません。すでに再署名したアプリは再インストールが必要です。macOS 27 へのアップグレードに手順をまとめています。
このページでは経緯と仕組みを説明します。すでにアプリを開けない場合は、macOS 27 へのアップグレードの修復手順へ進んでください。
コンテナとは
macOS の多くのアプリはサンドボックス内で動作します。システムは各アプリに ~/Library/Containers/<Bundle ID>/ という専用フォルダを割り当て、アプリはその中でのみ読み書きできます。App Store のアプリには必須で、WeChat や QQ Music など公式サイトから入手するアプリにも多く採用されています。複数のアプリで共有するデータは ~/Library/Group Containers/ に置かれます。
サンドボックスアプリかどうかは、エンタイトルメントに com.apple.security.app-sandbox があるかで確認できます。
codesign -d --entitlements - --xml /Applications/WeChat.app 2>/dev/null | grep -c app-sandbox
# 输出 1 就是沙盒应用見落としやすい点があります。メインプログラムがサンドボックスでなくても、そのコンテナを自由に移せるとは限りません。 Chrome や Edge のメインプログラムはサンドボックス内にありませんが、ウィジェットや機能拡張にはそれぞれコンテナがあり、それらの所有者はサンドボックスプロセスです。そのため AppPorts はメインプログラムに関係なく、Containers 内のすべてのディレクトリを同じように扱います。
コンテナデータを移す 3 つの方法
| 方法 | 結果 | 理由 |
|---|---|---|
| 外部ドライブにコピーし、元の場所にシンボリックリンクを残す | アプリは開くがデータを読めない。WeChat は保存場所を使用できないと表示する | サンドボックスはリンクの参照先を検証し、コンテナ外なら拒否する。外部ドライブでもデスクトップでも結果は同じ |
| シンボリックリンク + Ad-hoc 再署名 | macOS 26 以前では使えるが、27 では起動直後に終了する場合がある。WeChat で確認済み、QQ Music は引き続き開ける | 再署名でサンドボックス ID を取り除いたためリンクが機能する。しかしアプリとコンテナの所有関係も消し、macOS 27 ではその関係が確認される |
| 外部ドライブの APFS ボリュームを元のディレクトリにマウントする | 正常に動作し、署名も変更しない | パスがコンテナ外に出ないためサンドボックスの検証を通過する。外部ドライブのデータに対するシステムの許可を一度求められるので、許可すればよい |
3 つとも macOS 27 で実測済みです。元のログは実験記録：シンボリックリンクと実験記録：マウントポイントを参照してください。
再署名が変更するもの
Ad-hoc 再署名（codesign --force --deep --sign -）は、アプリから次の情報を取り除きます。
| 失われる情報 | 影響 |
|---|---|
com.apple.security.app-sandbox | サンドボックスの ID で動作しなくなる |
com.apple.security.application-groups | Group Containers 内の共有データを読めなくなる |
keychain-access-groups | キーチェーンのログイン状態やデータベースの鍵を読めなくなる |
| Team ID | コンテナの所有者をシステムが確認するときに一致しなくなる |
直後に問題が起きるとは限りません。通常のプロセスとして自分のコンテナを読む動作は、macOS 26 以前では許可されます。macOS 27 では、システムに元の署名の許可記録があると、コード要件の不一致によって拒否されます。
sandboxd rejected approval request from WeChat for kTCCServiceSystemPolicyAppData
(/Users/<user>/Library/Containers/com.tencent.xinWeChat/Data/Documents/xwechat_files): denied
runningboardd: termination reported by launchd (0, 0, 65280)同じマシン上の、同じ再署名済みの WeChat での結果です。
| システム | 動作 |
|---|---|
| macOS 26.6.2 | 2 日半継続して正常に使用 |
| macOS 27.0 | 起動するたびに約 0.4 秒で終了 |
以前問題がなかったことは、安全の証拠にはなりません
再署名後に数週間、数か月正常に使えていても、次のメジャーアップグレードで初めて問題が起きることがあります。アップグレードの前後に警告はありません。元の開発元の証明書は手元のコンピュータにはなく、消したエンタイトルメントを再署名で元に戻すことはできないため、再インストールが必要です。
ターミナルからは開ける理由
調査中に誤解しやすい点です。システムは「責任を負うプロセス」を基準に判定します。Finder や Dock から開く場合はアプリ自身がそのプロセスになり、自分の ID でアクセスを要求して拒否されます。ターミナルやフルディスクアクセスを持つ別のプログラムから起動すると、起動元が責任を負うため、アプリはそのアクセス権を借りる形になります。
ターミナルで起動できても、修復できたとは言えません。Finder / Dock から開けるかどうかで判断してください。
自分で確認する
/Applications/WeChat.app を調べたいアプリに置き換えてください。
# 1. 签名身份
codesign -dv --verbose=4 /Applications/WeChat.app 2>&1 | grep -E "Authority|TeamIdentifier|Signature"
# 2. 授权（正常输出一段 XML；只有 Executable= 一行说明已被抹掉）
codesign -d --entitlements - /Applications/WeChat.app
# 3. 容器里有没有指向外置盘的符号链接
find ~/Library/Containers/<Bundle ID> -maxdepth 6 -type l -exec readlink {} \; 2>/dev/null
# 4. 复现一次，看系统有没有拒绝
open -a /Applications/WeChat.app; sleep 3
log show --last 1m --style compact 2>/dev/null | grep -iE "rejected approval request|deny\(1\) file-read-data"| 確認結果 | 意味 |
|---|---|
Signature=adhoc かつ TeamIdentifier=not set | 再署名されている。開けない場合はアプリの再インストールが必要 |
手順 3 に出力があり、/Volumes/... を指している | コンテナ内に古いシンボリックリンクが残っているため、先に復元が必要 |
ログに kTCCServiceSystemPolicyAppData ... denied | 自分のコンテナへのアクセスが拒否されている。再署名が原因 |
ログに deny(1) file-read-data /Volumes/... | シンボリックリンクの追跡をサンドボックスが拒否している。データが外部ドライブにあることが原因 |
2 種類のログが同時に出る場合もあります。それぞれ別の問題なので、個別に対処する必要があります。
修復
順序は変えないでください。先に再インストールすると、アプリには依然としてシンボリックリンクが見えるため、再インストールが効かなかったように見えます。
- コンテナデータを復元：AppPorts の「アプリデータ」で、そのアプリの「Linked」状態のコンテナディレクトリをすべて一つずつ「Restore」し、ローカルに戻します。
- アプリを再インストール：公式の配布元から上書きインストールし、元の署名とサンドボックスを復元します。再インストールでコンテナデータは削除されません。
- 必要に応じてマウント移行：再インストール後、コンテナディレクトリに「マウント移行」が表示されます。外部ドライブで使い続けたい場合は、もう一度移行してください。
新しい AppPorts の「Restore Original Signature」は、完全なバックアップから元のアプリを復元でき、開発元の秘密鍵は不要です。旧形式の ID の名前しかない記録では、同じバージョンの公式アプリを選択するか、公式の配布元から再インストールする必要があります。署名のバックアップと復元を参照してください。署名を復元する前には、クラシックモードで移行したコンテナディレクトリを先に復元してください。
詳しい手順と、アプリ本体も外部ドライブへ移行している場合の対処は、macOS 27 の修復手順を参照してください。
実際の事例
2026 年 9 月、実機で確認した一連の経過です。
| 日時 | 出来事 |
|---|---|
| 9/15 04:46 | AppPorts が WeChat のチャットデータを外部ドライブへ移行し、元の場所にシンボリックリンクを作成 |
| 9/15 04:47 | AppPorts が WeChat を Ad-hoc で再署名 |
| 9/16 〜 9/18 | macOS 26.6.2 で WeChat を 2 日半正常に使用 |
| 9/18 04:46 | macOS 27.0 にアップグレード |
| 9/18 以降 | 起動するたびに約 0.4 秒で終了 |
| 9/18 05:04 | ユーザーがデータを復元して再度署名したが、問題は解消せず |
| 9/18 | データを復元し、公式サイトから WeChat を再インストールして正常に復旧。チャット履歴はすべて残った |
データは最初から最後まで壊れていませんでした。問題を潜ませていたのは再署名で、アップグレード前には症状がありませんでした。
関連ドキュメント
- macOS 27 へのアップグレード：アップグレード前の確認と修復手順
- マウント移行：新しい方式の使い方
- 外部ドライブに APFS が必要な理由
- 再署名とクラッシュ対策：現在の再署名機能の範囲