Running latest version of Overseerr via official sources. Going through localhost to access. Despite having a bind mount set up in Docker pointing to \\wsl.localhost\Ubuntu\overseerr-data , upon restarting docker (or my windows machine) the entirety of my Overseerr instance is reset. This means I end up having to re-log in to all of my services upon restart. Is this expected? If not, what is the next step?
#Overseerr data wiped despite bind mount in Docker( Windows)
prisma fjord
echo sand
What does your docker compose look like?
prisma fjord
Apologies @echo sand , where would I find the docker compose?
prisma fjord
Bumping as I'm still running into this issue
steep tinsel
How did you bring up the container?
prisma fjord
I'm gonna have a hard time finding the exact command, but essentially what is in the official instructions, except I point to a folder location within wsl.localhost @steep tinsel
steep tinsel
Yeah but we need to see exactly how you mapped the config folder
Try arrow key up on the terminal
OH wait
You can docker inspect
And check mountpath
prisma fjord
@steep tinsel
{
"Type": "bind",
"Source": "\\\\wsl.localhost\\Ubuntu\\overseerr-data",
"Destination": "/app/config",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
],```
prisma fjord
But it explicitly states Docker on Windows works differently than it does on Linux; it runs Docker inside of a stripped-down Linux VM. Volume mounts are exposed to Docker inside this VM via SMB mounts. While this is fine for media, it is unacceptable for the /app/config directory because SMB does not support file locking. This will eventually corrupt your database, which can lead to slow behavior and crashes. If you must run Docker on Windows, you should put the /app/config directory mount inside the VM and not on the Windows host. (This also applies to other containers with SQLite databases.) and when I did use the command in the instructions, I received a warning from overseerr
echo sand
And:
Named volumes, like in the example commands above, are automatically mounted inside the VM. Therefore the warning on the setup about the /app/config folder being incorrectly mounted page should be ignored.
If you used the command on the docs, ignore the warning.
There's no perfect way to detect that someone is running Overseerr in Docker and that they have the correct volume mounted.
prisma fjord
Gotcha, is there a way to easily spin up a new instance without wiping what I've currently got on my current overseerr?
echo sand
If you specify the same volume (using the same volume name) for the new instance it will use the same configuration and keep the request history etc
Will that instance be in a Docker container on the same host?
If not, you'd have to copy the contents of the volume that you initially created to the new location
Then set that location as the location for the volume for the new Overseerr instance.
prisma fjord
Same host, correct
echo sand
Then you should only need to change the other parameters apart from the volume mount and you should be good to go
Curious why you'd do that though since it's the same host. Usually people do that when moving the container to another machine
prisma fjord
The thought is that I'd want to spin up a new instance since I'm pointing to the wrong bind
My original command was something along the lines of docker run -d --name overseerr -e LOG_LEVEL=debug -e TZ=Asia/Tokyo -p 5055:5055 -v "\\wsl.localhost\Ubuntu\overseerr-data:/app/config" --restart unless-stopped sctx/overseerr:latest btw
echo sand
Ah yes
The volume mount doesn't look good
It should be overseerr-data:/app/config if you created a volume named that like in the docs
prisma fjord
That did it, though I can't find my docker file locations so copying the data over was a no go