The source qBittorrent problem had two layers. First, qBittorrent must save to a path that exists inside the container. Second, the qBittorrent process must have write permission to the host folder behind that container path. The user had already solved the mapping layer—the folder was visible—but the execution log still showed Permission Denied.
Het oorspronkelijke qBittorrent-probleem had twee lagen. Ten eerste moet qBittorrent opslaan op een pad dat binnen de container bestaat. Ten tweede moet het qBittorrent-proces schrijfrechten hebben voor de hostmap achter dat containerpad. De gebruiker had de koppelingslaag al opgelost — de map was zichtbaar — maar het uitvoeringslogboek toonde nog steeds Permission Denied. De community-oplossing maakte een speciale downloadmap aan en gebruikte een zeer ruime chmod -R 777 777 als snelle test van de rechten. De oorspronkelijke poster bevestigde dat downloads daarna werkten. Dat resultaat bewijst dat de fout een probleem met schrijfrechten was, maar
zou niet de permanente aanbeveling op een huidig systeem moeten zijn.
/Movies-TV.De bron gebruikte:
-
Host:
/media/Main Storage/Media/Movies -
Container:
/Movies-TV
In qBittorrent moet het opslagpad /Movies-TV/..., niet het onbewerkte hostpad.
De zichtbaarheid bewees dat de koppeling werkte; Permission Denied bewees dat schrijven niet lukte
In het uitvoeringslogboek van qBittorrent van de gebruiker stond Permission Denied. Dat verschilt van No such file or directory:
- No such file/directory: de koppeling of het pad is waarschijnlijk onjuist.
- Permission denied: de container kan het pad bereiken, maar er niet naar schrijven.
Een speciale downloadmap maakt het eenvoudiger om de rechten correct in te stellen
De community maakte een submap aan, zoals:
/media/Main Storage/Media/Movies/qbittorrent-downloadsen de bestemmingsmap aan de kant van de container van qBittorrent instellen op:
/Movies-TV/qbittorrent-downloadsDit is beter dan een downloader schrijfrechten geven voor een volledige mediamap als die slechts één stagingmap nodig heeft.
chmod 777 was een diagnostische snelkoppeling, geen goed model voor definitieve rechten
In het antwoord van de community werd recursief chmod 777 en de oorspronkelijke poster bevestigde dat dit het probleem oploste. Dat bevestigt het oorzakelijke verband, maar voor iedereen schrijfbare rechten geven elk lokaal proces de mogelijkheid om naar de map te schrijven.
Een veiligere permanente oplossing is om de runtime-UID/GID van de qBittorrent-container vast te stellen en alleen die gebruiker/groep de vereiste schrijfrechten te geven.
Controleer het eigenaarschap voordat je dit wijzigt
Nuttige controles in alleen-lezenmodus zijn onder meer het inspecteren van de eigenaar/groep en modus van de map voordat je iets wijzigt. Als qBittorrent met een configureerbare PUID/PGID werkt, stem deze waarden dan af op een hostgroep die schrijfrechten heeft voor de downloadmap.
Vermijd recursieve wijzigingen van het eigenaarschap van een volledige gedeelde mediabibliotheek wanneer slechts één map schrijfbaar hoeft te zijn.
Het huidige ZimaOS maakt app-volumepaden expliciet
De huidige documentatie van IceWhale legt uit dat applicaties uit de App Store binnen containers draaien en dat hun belangrijke mappen aan echte hostopslag zijn gekoppeld. Deze toewijzingen kunnen worden bekeken en bewerkt via de app-instellingen.
Gebruik het huidige Docker-padmodel van ZimaOS voordat je machtigingen bewerkt.
Scheid de tijdelijke downloadmap van de uiteindelijke mediabibliotheek
Een veelgebruikte architectuur is:
- qBittorrent schrijft naar een speciale downloadmap;
- Sonarr/Radarr of een andere organisator importeert voltooide bestanden;
- Jellyfin/Plex leest de uiteindelijke mediabibliotheek, vaak alleen-lezen.
Hierdoor krijgt elke applicatie alleen de toegang die deze nodig heeft.
Test eerst met één kleine download
Na het wijzigen van de toewijzing of machtiging:
- start qBittorrent opnieuw;
- bevestig dat het opslagpad binnen de container wordt opgelost;
- download een klein legaal testbestand;
- controleer het uitvoeringslogboek;
- controleer of het bestand op de bedoelde hostopslag verschijnt.
Veelgestelde vragen over het downloadpad van qBittorrent
Was de bronvolumetoewijzing zelf onjuist?
De community concludeerde dat het zichtbaar en correct was; de resterende fout betrof schrijfrechten.
Zorgde chmod 777 ervoor dat het brongeval werkte?
Ja, en de oorspronkelijke poster bevestigde dat het werkte. Dit moet worden gezien als een brede diagnostische sneloplossing, niet als de aanbevolen permanente machtiging.
Welk pad moet qBittorrent intern gebruiken?
Het pad aan de containerzijde dat is gedefinieerd in de volumetoewijzing van ZimaOS, zoals /Movies-TV/qbittorrent-downloads.
