Als qBittorrent een map in ZimaOS kan zien, maar elke torrent onmiddellijk mislukt, is alleen het wijzigen van het downloadpad in qBittorrent niet voldoende. De map op de host moet eerst in de Docker-container worden gemount en de gebruiker die qBittorrent in die container uitvoert, moet schrijfrechten hebben voor de gemounte map op de host.
Dat was wat er gebeurde in de IceWhale Community-thread van januari 2026. De oorspronkelijke poster koppelde een mediamap aan /Movies-TV, maar in het uitvoeringslogboek van qBittorrent stond Permission denied. Een speciale submap plus schrijfrechten op de host loste het probleem in de oorspronkelijke situatie op. De community gebruikte chmod -R 777 als snelle oplossing, maar de huidige richtlijnen van LinuxServer geven de voorkeur aan het afstemmen van PUID/PGID op het eigenaarschap op de host, in plaats van de map voor iedereen schrijfbaar te maken.
Hostpad versus containerpad
Een ZimaOS-pad is niet automatisch zichtbaar in qBittorrent. Een normale koppeling is:
Host: /DATA/Downloads
Container: /downloadsqBittorrent moet vervolgens opslaan in een containerpad zoals /downloads/qbittorrent.
De oorspronkelijke koppeling
Host: /media/Main Storage/Media/Movies
Container: /Movies-TV
Maak een speciale downloadmap
De werkende indeling uit de community maakte deze map aan:
/media/Main Storage/Media/Movies/qbittorrent-downloadsen gebruikte deze map vervolgens in qBittorrent:
/Movies-TV/qbittorrent-downloadsControleer de rechten
ls -ld "/media/Main Storage/Media/Movies"
ls -ld "/media/Main Storage/Media/Movies/qbittorrent-downloads"Als de map bestaat, maar het logboek Permission denied vermeldt, heeft de containeridentiteit geen schrijfrechten.
De door de community bevestigde snelle oplossing
chmod -R 777 "/media/Main Storage/Media/Movies/qbittorrent-downloads"De oorspronkelijke poster bevestigde dat dit werkte. 777 geeft echter in brede zin lees-, schrijf- en uitvoerrechten, dus gebruik dit als diagnose of tijdelijke oplossing en niet als ideaal model voor permanente rechten.
Voorkeursoplossing voor de lange termijn: PUID en PGID afstemmen
De huidige LinuxServer-qBittorrent-image ondersteunt PUID en PGID specifiek om conflicten met rechten op bind mounts te voorkomen. De documentatie raadt aan het eigenaarschap van de map op de host compatibel te maken met de ID's die aan de container worden doorgegeven.
LinuxServer-documentatie voor qBittorrent
PUID=1000
PGID=1000Deze waarden zijn slechts voorbeelden. Controleer het bedoelde hostaccount met id USERNAME en gebruik de werkelijke ID's of een compatibele gedeelde groep.
Herstarten en testen
- Sla de volumekoppeling op.
- Herstart of maak qBittorrent opnieuw aan.
- Stel het standaardpad voor opslaan in op het gekoppelde containerpad.
- Start een kleine testdownload.
- Lees Extra → Uitvoeringslogboek als de download nog steeds mislukt.
Wat de fouten betekenen
- Permission denied: het pad bestaat, maar is niet schrijfbaar.
- No such file or directory: het containerpad ontbreekt of is onjuist gekoppeld.
Veelgestelde vragen over het downloadpad van qBittorrent
Moet qBittorrent het ZimaOS-hostpad gebruiken?
Nee. Normaal gesproken moet het de containerzijde van het pad gebruiken die in de volumekoppeling is gedefinieerd.
Heeft chmod 777 het probleem in de oorspronkelijke thread opgelost?
Ja. De auteur bevestigde dat dit werkte, maar beperktere PUID/PGID- of groepsrechten zijn op de lange termijn veiliger.
Waarom kan qBittorrent een map zien, maar er niet naar schrijven?
Zichtbaarheid via een Docker-mount en schrijfrechten op het bestandssysteem zijn verschillende zaken. Een gekoppelde map kan leesbaar zijn, maar niet schrijfbaar voor de containergebruiker.
