Błąd uprawnień był w rzeczywistości pomyleniem ścieżek
Użytkownik ZimaOS musiał edytować plik config.php aplikacji Nextcloud, aby dodać adres tailnetu do zaufanych domen. Polecenia takie jak chown i usermod nie pomogły, ponieważ najważniejsze pytanie nie dotyczyło tego, kto jest właścicielem pliku, lecz tego, z której przestrzeni nazw systemu plików korzystało polecenie.
Wątek zakończył się pomyślnym rozwiązaniem po sprawdzeniu punktów montowania kontenera Nextcloud. Ten sam plik był dostępny pod jedną ścieżką na hoście ZimaOS, a pod inną wewnątrz kontenera. Ścieżka kontenera podana z poziomu hosta nie zadziała tylko dlatego, że wygląda poprawnie w poradniku Nextcloud.
Sprawdź punkt montowania kontenera przed zmianą uprawnień
Najpierw ustal nazwę uruchomionego kontenera Nextcloud:
docker ps --format "table {{.Names}}\t{{.Image}}"Następnie sprawdź jego punkty montowania, zastępując symbol zastępczy rzeczywistą nazwą kontenera:
docker inspect <nextcloud-container-name> --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'W tym przypadku wynik pokazał:
/DATA/AppData/nextcloud/var/www/html -> /var/www/htmlLewa strona to ścieżka na hoście. Prawa strona to ścieżka widoczna wewnątrz kontenera. To mapowanie wyjaśnia, dlaczego zmiana niepowiązanego katalogu lub użycie ścieżki kontenera z poziomu hosta nie rozwiązało problemu.
Podczas edycji z poziomu ZimaOS użyj ścieżki hosta
W powłoce hosta ZimaOS użytkownik znalazł plik pod adresem:
/DATA/AppData/nextcloud/var/www/html/config/config.phpOdpowiednie polecenie edycji po stronie hosta to:
vim /DATA/AppData/nextcloud/var/www/html/config/config.phpPrzed edycją w wątku zalecono sprawdzenie zarówno pliku, jak i jego katalogu nadrzędnego:
ls -l /DATA/AppData/nextcloud/var/www/html/config/config.php
ls -ld /DATA/AppData/nextcloud/var/www/html/configZaobserwowane uprawnienia pliku to 640, a jego właścicielem był www-data:www-data. Te informacje są istotne, ale ostateczną przeszkodą nadal był kontekst ścieżki. W odpowiedzi wyraźnie odradzono losowe zmienianie właściciela przed zlokalizowaniem właściwego źródła montowania.
Użyj ścieżki kontenera dopiero po wejściu do kontenera
Alternatywnie możesz wejść do uruchomionego kontenera i edytować plik bezpośrednio w nim:
docker exec -it nextcloud sh
vi /var/www/html/config/config.phpWewnątrz kontenera ścieżka /var/www/html/config/config.php jest prawidłowa. Z poziomu hosta ta sama ścieżka wskazuje na własny główny system plików hosta, a nie na zamontowany katalog danych Nextcloud.
Ostrzeżenie dotyczące konfiguracji Dockera było osobnym problemem
Zarówno docker inspect, jak i docker exec wyświetlały ostrzeżenie, że nie można otworzyć pliku /DATA/.docker/config.json. W odpowiedzi wyjaśniono, że jest to ostrzeżenie dotyczące konfiguracji interfejsu wiersza poleceń Dockera, a nie przyczyna problemu z dostępem do pliku Nextcloud. Użytkownik mógł kontynuować pracę po zrozumieniu właściwej ścieżki hosta i kontenera.
FAQ
Dlaczego zmiana właściciela nie naprawiła pliku konfiguracyjnego Nextcloud?
Polecenia wykonywano bez wcześniejszego potwierdzenia rzeczywistego źródła montowania. Zmiana uprawnień w niewłaściwym katalogu hosta nie wpływa na plik znajdujący się w zamontowanej ścieżce danych Nextcloud.
Czy plik config.php należy edytować z poziomu hosta czy wewnątrz kontenera?
Obie metody mogą działać. Z hosta użyj pełnej ścieżki źródłowej /DATA/AppData/... albo najpierw wejdź do kontenera i użyj ścieżki /var/www/html/.... Nie mieszaj tych dwóch kontekstów ścieżek.
