DSM 6.2 How to edit Docker container files with Portainer console

[Telos]

I'm running qBittorrrentVPN in Docker. My problem is likely relevant for qBittorrent as well.

I wanted to update the Jackett search plugin. The default setting uses IP 127.0.0.1:9117 and no API key.

The jackett.json file with this information resides at \\NAS1\docker\qbittorrentvpn\config\qBittorrent\data\nova3\engines\

When I edited this file via SMB (Win10) to show my NAS IP and Jackett API, and restarted the container, the default values remained. I opened the folder via File Station and the Win10 edits were present. In the container I deleted the plugin and refreshed and still the default values were present.

I opened the Portainer console for this container and noticed that the jacket.json file did not contain the edits I saw in File Station... This surprised me as I thought that my /config mapping on the NAS would be equal to the /config present in the container. Not fully understanding this... I decided to edit the container file directly, but found no way to call vi/vim/nano.

So my questions at this point are...

Why are the edits made on the NAS' file not reflected in the container file?
How can I edit the container file? Is there a "root" login necessary to edit this file?

 

[Akira]

Hi Telos, what exactly are you trying to do? Use the VPN in your qbittorrent container so that jackett accesses the internet via that?

 

[Telos]

what exactly are you trying to do

I need to edit "jacket.json" with my Jacket API, and the URL to my Jacket container, so that the Jackett search plugin functions.

 

[Rusty]

How can I edit the container file?

How are your qbit volumes mappings atm?

 

[Telos]

How are your qbit volumes mappings atm?

\docker\qbittorrentvpn\config to \config

 

[one-eyed-king]

Are you sure the ENV variables in your manualy created container settings (or the compose file that creats them) don't work againt your manual changes in the config files?

Some entrypoint scripts allways render the config files new, some just update exsting configs, some only render the configs the first time created... Some only update particular "low-level" in the configurations.

I have no idea how the entrypoint script the specific qbittorrentvpn repos handels it. But it might be worth checking the configured env of the container (or compose file).

If you share which exact image you use (=as in ${repo}:{tag}), I can take a look on how the entrypoint script works.

 

[Telos]

If you share which exact image you use (=as in ${repo}:{tag}), I can take a look on how the entrypoint script works.

GitHub - MarkusMcNugen/docker-qBittorrentvpn: Docker container which runs a headless qBittorrent client with WebUI and optional OpenVPN

 

[one-eyed-king]

This is the entrypoint script: docker-qBittorrentvpn/start.sh at focal · MarkusMcNugen/docker-qBittorrentvpn
The only file it (re-)creates is /config/openvpn/credentials.conf inside the container.

Additionaly it will pick the first *.ovpn file in /config/openvpn and changes it to use "auth-user-pass credentials.conf" (the file previously created) and makes sure to convert dos to unix line endings (there is no harm if the already are).

It also writes the lost of NAME_SERVERS from the ENV variable into /etc/resolv.conf.

There is no evidence that the config is rendered based on the ENV variables. The only chaning part is related to authentification and correction of line ending.

The pressing question that remains is: why does your bind-mount volume mapping not work? You should see the same .ovpn config in your share and inside the container.

UPDATE:
I missed that it calls this script to actualy start qBittorent docker-qBittorrentvpn/start.sh at focal · MarkusMcNugen/docker-qBittorrentvpn. Let me check it as well.

If /config/qBittorrent/config/qBittorrent.conf does not exists, it copies the default confing from /etc/qbittorrent/qBittorrent.conf to that location.

Then it inline replaces some settings in /config/qBittorrent/config/qBittorrent.conf:
- WEBUI_PORT
- INCOMING_PORT

and calls qbittorrent.init to actualy start qBittorrent.

Same conclusion as before: check why your bind-mount volume mapping seem not to apply.

 

[Telos]

Same conclusion as before: check why your bind-mount volume mapping seem not to apply.

Well I'm puzzled. Although the VPN is working, it is not using the OPVN file I currently have in place, but one I used some time ago, which no longer exists in the local folder (???)

With the container stopped, I tried to edit the jackett.json with the administrator acct that is set with PGID/PUID in the ENV's, and is the owner of the local copy of jackett.json ... yet, got this when I went to save:

Ideas on what to look at next?

 

[one-eyed-king]

Well I'm puzzled. Although the VPN is working, it is not using the OPVN file I currently have in place, but one I used some time ago, which no longer exists in the local folder (???)

Almost sounds like the source for the mount target /config is different, then what you think it is.

Seems like qBitorrent has it's own user and account settings. I have no idea about what can be configured there.

Though, I can tell that it is NOT related to filesystem permissions:

The entrypoint script applies chown -R "${PUID}":"${PGID}" "/config/openvpn" &> /dev/null to all openvpn configuration and chown -R ${PUID}:${PGID} /config/qBittorrent to all qBitorrent configurations. Which should work as inside the Dockerfile no USER instruction is set -> the image should start as root user. The qBittorent process later is then started with whatever is configured as PUID:PGID.

You might want to check the output of docker container inspect --format '{{json .Mounts}}' ${container_name_or_id}| jq

 

[Telos]

You might want to check the output of docker container inspect --format '{{json .Mounts}}' ${container_name_or_id}| jq

Major embarrassment... I should have caught this from @Rusty 's comment.

In my docker folder... I have an old application folder "qbttorrentvpn" which I once used for this container. Several months ago, I created a new folder "qbtvpn" which is the active folder for the container configs. After editing "jackett.json" in the correct folder, my search plugin works fine.

Thanks to all you offered help. I learned a lot from your postings. Your feedback ultimately thawed out my brain to see the "user error" so prevalent in my endeavors.