Closed mtalexan closed 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.
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.
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.
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:/config
when the contents of/docker/jackett/config
contain the actual configuration files for Jackett should function.Current Behavior
With Jackett, setting the
XDG_CONFIG_HOME
within 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 aJackett
subfolder to contain the logs, and will only look in the$XDG_CONFIG_HOME/Jackett
subfolder for the configuration.Steps to Reproduce
mkdir -p /docker/jackett/{config,blackhole}
/docker/jackett/docker-compose.yml
cd /docker/jackett
docker-compose up -d
Jackett
folder was created at/docker/jackett/config/Jackett
and 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.json
file 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/Jackett
within the container instead.