Community Solution

Set the Correct qBittorrent Download Folder on ZimaOS

A ZimaOS user mapped qBittorrent downloads to a second drive but kept entering the ZimaOS host path inside qBittorrent. The confirmed fix was to use the Docker container path /downloads instead.

If qBittorrent is still saving downloads to the ZimaOS system drive even after you selected another HDD in the app settings, check which path you entered inside qBittorrent itself. In the November 2025 IceWhale Community thread, the secondary drive was already mounted into the qBittorrent container, but the user entered the ZimaOS host path instead of the Docker container path.

The confirmed fix was simple: use /downloads inside qBittorrent, not the ZimaOS host path such as /media/GERAL/downloads. Changing PUID/PGID to 0/0 did not solve the source case; correcting the path did, and the original author explicitly confirmed that downloads then worked.

The Core Difference: Host Path vs Container Path

A Docker volume mapping has two sides:

HOST_PATH:CONTAINER_PATH

For example:

/media/GERAL/downloads:/downloads

ZimaOS sees the left side. qBittorrent runs inside the container and should normally use the right side.

Correct inside qBittorrent: /downloads
Wrong inside qBittorrent:   /media/GERAL/downloads

What the Original User Had Configured

ZimaOS qBittorrent settings showing the secondary GERAL drive download mapping
The original post shows qBittorrent configured with storage on the secondary GERAL drive.
qBittorrent download settings using a ZimaOS host path instead of the Docker path
The qBittorrent setting was using a host-side path instead of the mounted container path.
ZimaOS storage path for the GERAL drive used by the qBittorrent container
ZimaOS exposes the physical host path, but qBittorrent does not need to use that same path string internally.
qBittorrent download folder field from the ZimaOS troubleshooting thread
The confirmed fix was to use the mounted container path /downloads.

Why Changing PUID and PGID Did Not Fix This Case

A community reply first suggested testing different PUID/PGID values, including 0/0. The original author tried that and reported that it did not work.

That matters because it separates this case from a permission problem. Root privileges do not make an unmapped host path become the correct container path.

Current LinuxServer qBittorrent Uses the Same Pattern

The current LinuxServer qBittorrent Docker documentation uses:

/path/to/downloads:/downloads

and defines /downloads as the download location inside the container. That matches the community fix exactly.

LinuxServer qBittorrent Docker documentation

How to Fix the Download Folder

  1. Open the qBittorrent app settings in ZimaOS.
  2. Find the download volume mapping.
  3. Confirm the desired secondary-drive folder is on the ZimaOS host side.
  4. Confirm the container side is a stable path such as /downloads.
  5. Save and restart the app if the Docker mapping changed.
  6. Open qBittorrent WebUI.
  7. Go to Tools → Options → Downloads.
  8. Set the Default Save Path to /downloads or a subfolder such as /downloads/complete.
  9. Start a small test torrent and verify which physical drive receives the data.

When PUID/PGID Permissions Do Matter

If /downloads is correct but qBittorrent logs Permission denied, then check ownership and permissions. LinuxServer's image supports PUID and PGID specifically for host bind-mount permissions.

That is a different failure from the source thread. Diagnose path correctness first, permissions second.

ZimaOS qBittorrent Download Folder FAQ

Why does qBittorrent still use the ZimaOS system drive?

In the source case, qBittorrent was configured with the host path instead of the mounted container path.

What path fixed the original thread?

/downloads. The author confirmed it worked.

Should I set PUID and PGID to 0?

Not for this problem. The original author tried that without success. Use the correct container path first.