Closed mtalexan closed 4 years ago
aptalca
commented
4 years ago Is the complaint that there is an additional folder layer in the config folder? I don't see that as an issue. We claim that all the config and user data resides under /config and that is accurate, whether in a subfolder or not. What you're describing is the intended behavior.
mtalexan
commented
4 years ago You are correct that it's accurate as described, but if you're migrating existing data then it fails to use the migrated data in a non-obvious way.
My recommendation is only that's the README be updated to tell the user to point to /config/Jackett within the container rather than /config. It was only after some debugging, trial and error, and a lot of research that I even discovered that was the source of my migration problems.
aptalca
commented
4 years ago Migrate from where? We don't officially support any migration from a non-linuxserver image. If you do any migration from bare metal, our recommendation would be the same with any of our images:
We never claim structure parity with any other install method. In our images, /config folder just means it's a folder we picked to store all necessary files and folders meant to be persistent, in a structure that is feasible and convenient for us to implement. Many of our upstream apps have multiple locations for the config and user data, we structure all under /config in a manner we pick.
mtalexan
commented
4 years ago I was migrating from a bare metal test server where Jackett had been installed under an active user name. I'd previously migrated the content between test servers, and all content defaults to being directly within the /home/${USER}/.config/Jackett folder.
You don't have to claim to support migration, but the README as written makes it sound like migrating would simply be a matter of moving those files to the host-side volume root of /config.
Alternatively, clarifying that "/config gets mapped to $XDG_CONFIG_HOME, which is the log and config location Jackett is configured to use" would also help clarify and put the documentation gap on Jackett directly. I had to dig into this Dockerfile directly to determine how the /config mapping was being used, and how that related to Jackett, identify seemingly inconsequential differences, then stumble on a closed (as won't fix) Jackett Issue about this exact issue when using $XDG_CONFIG_HOME.
The issue isn't technically with this docker image, it's actually with Jackett, but some rephrasing here in the README could help a lot with tracking down any problems.
Jackett creates a subfolder within the config volume that gets used, which mismatches the description of the usage.
Expected Behavior
Using option
-v /docker/jackett/config:/configwhen the contents of/docker/jackett/configcontain the actual configuration files for Jackett should function.Current Behavior
With Jackett, setting the
XDG_CONFIG_HOMEwithin the container is necessary to define the logging path, and can optionally be used to specify the configuration path if the--DataPath=command-line option isn't used. However, unlike the--DataPath=option, Jackett will always create aJackettsubfolder to contain the logs, and will only look in the$XDG_CONFIG_HOME/Jackettsubfolder for the configuration.Steps to Reproduce
mkdir -p /docker/jackett/{config,blackhole}/docker/jackett/docker-compose.ymlcd /docker/jackettdocker-compose up -dJackettfolder was created at/docker/jackett/config/Jackettand all logs from the running Jackett process are going into it. Also notice the/docker/jackett/config/Jackett/{DataProtection,Indexers}folders that were created, and the/docker/jackett/config/Jackett/ServerConfig.jsonfile that are the actual configuration files for Jackett.Environment
OS: Ubuntu 18.04.3 CPU architecture: x86_64
How docker service was installed:
Command used to create docker container (run/create/compose/screenshot)
See steps to reproduce above
Docker logs
Recommended Fix
Update the README.md to tell the user to mount their config folder at
/config/Jackettwithin the container instead.