権限エラーの本当の原因はパスの取り違えでした
ZimaOSユーザーは、tailnetアドレスをtrusted domainsに追加するため、Nextcloudのconfig.phpを編集する必要がありました。chownやusermodなどのコマンドで解決しなかったのは、最初に確認すべきことがファイルの所有者ではなく、そのコマンドがどのファイルシステム名前空間で実行されているかだったためです。
ユーザーがNextcloudコンテナのマウントを確認したことで、スレッドは解決に至りました。同じファイルが、ZimaOSホスト上ではあるパスに、コンテナ内では別のパスに表示されていました。ホスト上でコンテナ内のパスを入力しても、Nextcloudのガイドに記載されているように見えるというだけでは機能しません。
権限を変更する前にコンテナのマウントを確認する
まず、実行中のNextcloudコンテナを特定します。
docker ps --format "table {{.Names}}\t{{.Image}}"次に、プレースホルダーを実際のコンテナ名に置き換えて、マウントを確認します。
docker inspect <nextcloud-container-name> --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'このケースでは、次の出力が表示されました。
/DATA/AppData/nextcloud/var/www/html -> /var/www/html左側がホスト上のパスです。右側はコンテナ内から見たパスです。この対応関係により、無関係なディレクトリを変更したり、ホスト上でコンテナ内のパスに移動したりしても問題が解決しなかった理由が分かります。
ZimaOSから編集する場合はホスト側のパスを使う
ZimaOSホストのシェルから、ユーザーは次の場所にファイルを見つけました。
/DATA/AppData/nextcloud/var/www/html/config/config.phpしたがって、ホスト側で編集するコマンドは次のとおりです。
vim /DATA/AppData/nextcloud/var/www/html/config/config.php編集前に、ファイルとその親ディレクトリの両方を確認することがスレッドで推奨されました。
ls -l /DATA/AppData/nextcloud/var/www/html/config/config.php
ls -ld /DATA/AppData/nextcloud/var/www/html/config確認されたファイルモードは640で、所有者はwww-data:www-dataでした。この情報も重要ですが、最終的な障害は依然としてパスのコンテキストでした。実際のバインドマウント先を特定する前に、無作為に所有権を変更しないよう明確に案内されています。
コンテナ内に入った後だけコンテナ側のパスを使う
別の方法として、実行中のコンテナに入って、そこでファイルを編集できます。
docker exec -it nextcloud sh
vi /var/www/html/config/config.phpコンテナ内では、/var/www/html/config/config.phpが正しいパスです。ホスト上では、同じパスはホスト自身のルートファイルシステムを指し、バインドマウントされたNextcloudディレクトリを指しません。
Dockerの設定警告は別の問題
docker inspectとdocker execの両方で、/DATA/.docker/config.jsonを開けないという警告が表示されました。この警告はDocker CLIの設定に関するものであり、Nextcloudのファイルアクセス問題の原因ではないと説明されています。ホスト側とコンテナ側の正しいパスの違いを理解すれば、ユーザーは作業を続行できました。
FAQ
所有権を変更してもNextcloudのconfig.phpが直らなかったのはなぜですか？
実際のバインドマウント元を確認する前に、コマンドを実行していたためです。間違ったホストディレクトリの権限を変更しても、マウントされたNextcloudデータパス内のファイルには影響しません。
config.phpはホスト上とコンテナ内のどちらで編集すべきですか？
どちらでも構いません。ホスト上では完全な/DATA/AppData/...ソースパスを使い、コンテナ内では先にコンテナへ入ってから/var/www/html/...を使います。2つのパスコンテキストを混在させないでください。
