The source clearly proves one thing: qBittorrent could reach the mapped external Btrfs folder, but the process could not create its incomplete subdirectory. The error was Permission Denied, not “path not found.” That makes filesystem identity/permission the strongest troubleshooting layer.
The thread does not prove the permanent fix. The only reply said UID 1000 did not exist on that ZimaOS system and suggested testing the container as root. The original poster never returned with a successful result. Running qBittorrent as root should therefore be treated only as a narrow diagnostic—not a recommended final configuration.
The Volume Mapping Was Explicit
The source mapped:
/media/SSD-1TBStorage/Downloads → /downloadsInside qBittorrent, the application attempted to create:
/downloads/incomplete/...Because the error was permission denied, the mapping likely existed and the container reached the host filesystem.
The Host Folder Had Group Write Permission
The user showed:
drwxrwxr-x 1 1000 samba /media/SSD-1TBStorage/Downloadsand said the container ran as UID/GID 1000. They also tried chown -R 1000:1000 and chmod -R 775.
The fact that the error returned means one of those assumptions—actual runtime identity, parent-directory access, mount behavior, or effective permissions—was incomplete.
Do Not Hard-Code a ZimaOS UID from a Forum Reply
The community responder claimed the first ZimaOS user used UID 999 rather than 1000. Even if that was correct for one build, user IDs can vary by platform/version and the qBittorrent container may use a separate PUID/PGID identity.
Inspect the actual current container configuration and process identity instead of guessing.
Running as Root Can Confirm a Permission Layer but Should Not Be Permanent
If a container works only when run as UID 0, that strongly suggests the mapped path denies the normal application identity. It does not mean qBittorrent should remain root forever.
A downloader exposed to web/network input should have only the filesystem privileges it needs.
Check Every Parent Directory in the Host Path
Write access to the final Downloads directory is not enough if the container identity cannot traverse one of the parent directories. Inspect the full path and any ACLs, not only the last directory's mode bits.
Btrfs Was Present, but the Source Did Not Prove Btrfs Caused the Failure
The SSD used Btrfs, but ordinary Unix ownership/permissions still apply. Nothing in the thread proves a Btrfs-specific bug, subvolume policy, or read-only mount caused the error.
Check the mounted filesystem state before blaming the filesystem type.
Current ZimaOS Exposes App Volume Mappings Explicitly
Current IceWhale documentation explains host-side and container-side paths and lets users edit app storage mappings from app settings.
Use the current ZimaOS Docker path model before altering ownership.
Use a Dedicated qBittorrent Download Folder
Give qBittorrent write access to a purpose-built download/staging folder instead of an entire media or backup volume. Sonarr/Radarr can then import/move completed files under their own controlled permissions.
A Safer Permanent Permission Workflow
- Confirm the exact host-to-container mapping.
- Inspect the qBittorrent container's actual UID/GID/PUID/PGID.
- Inspect the host folder and parent-directory permissions.
- Create a small dedicated test directory.
- Grant only the needed user/group write access.
- Restart the app and test one small legal download.
qBittorrent Btrfs Permission FAQ
Was the final source fix confirmed?
No. The thread ends after one community reply.
Does Permission Denied prove the Docker volume mapping is absent?
No. It usually means the path is reachable but the process cannot perform the requested write.
Should qBittorrent run permanently as root?
No. Root can be a diagnostic test, but the permanent fix should use the least filesystem privilege required.
