The confirmed fix in this thread was to set qBittorrent’s Default Save Path to the Docker container path /downloads, not the ZimaOS host path. The user had already mounted the secondary HDD correctly; qBittorrent was simply being told to save to a path that only the host understood.
Changing PUID/PGID to root did not solve the source case. Once the path was corrected, the original author explicitly confirmed that downloads worked.
What the Original Mapping Looked Like
The important mapping is conceptually:
Host: /media/GERAL/Downloads → Container: /downloads
ZimaOS sees the left side. qBittorrent runs inside Docker and should normally use the right side.
The Wrong Path Was Inside qBittorrent
The qBittorrent WebUI was configured with /media/GERAL/Downloads. That host path was not the path exposed to the application inside the container.
The current qBittorrent folder guide documents the same source case and verified resolution.
Why Root PUID and PGID Did Not Help
Permissions and path visibility are different problems. Running as root cannot make an unmounted host path magically appear inside a container. First verify the container path; only investigate ownership when the correct mapped path returns Permission denied.
The adjacent qBittorrent permission guide covers that second failure mode.
Current Docker Images Use the Same Pattern
The current LinuxServer qBittorrent image documents a downloads volume mounted to /downloads. See the LinuxServer qBittorrent docs before changing a customized app definition.
Bottom Line
If ZimaOS already maps your target disk into qBittorrent as /downloads, use /downloads or a subfolder below it inside qBittorrent. Do not paste the ZimaOS host path into the application unless that exact path is also mounted into the container.
