Closed codetheweb closed 2 years ago
That TZ is not valid US/Eastern
would be east coast.
Why are you running the container as root PUID/PGID?
Also please try the container as a test without the https://github.com/jawilson/deluge-piaportplugin plugin, they may need to make updates to that plugin now that this image has been rebased to Alpine.
I had similar issues. Likely due to the replatform. I found that rolling back to tag 2.0.5-0202202181752ubuntu20.04.1-ls140 corrected the issue for me. I don't have any plugins configured.
I don't think this is a permissions issue, as in my tests, the file was still initialised successfully from the torrent.
I had similar issues. Likely due to the replatform. I found that rolling back to tag 2.0.5-0202202181752ubuntu20.04.1-ls140 corrected the issue for me. I don't have any plugins configured.
I don't think this is a permissions issue, as in my tests, the file was still initialised successfully from the torrent.
Post your setup. Me and our team cannot replicate this, so there is an outside variable here.
Yep, I was able to reproduce it with jawilson/deluge-piaportplugin disabled. I'm currently trying to reproduce it with a clean config on macOS, we'll see how that goes.
All through my mobile, so please excuse any formatting issues. Docker compose bit:
deluge:
image: linuxserver/deluge
container_name: deluge
network_mode: "service:vpn"
depends_on: ['vpn']
environment:
- PUID=995
- PGID=995
- UMASK_SET=000
- UMASK=000
- TZ=${TZ}
volumes:
- ${USERDIR}/deluge:/config
- /media/drv1/VIDEO/Torrents:/downloads
restart: unless-stopped
Plugins directory is empty. Perhaps the other factor is that I am using mergerfs filesystem for the downloads directory. This should be mostly abstracted away, but I have seen oddities before. I have not tried to set downloads to a local folder.
Perhaps the other factor is that I am using mergerfs filesystem for the downloads directory. This should be mostly abstracted away, but I have seen oddities before.
Hmm, I'm also using mergefs.
I can confirm that the issue is with mergerfs. I created a clean Deluge container (new config), mounted to my boot SSD, and it worked fine. I shutdown the container, changed the mountpoint to my mergerfs mount, and now I'm getting the same "No such device" error.
I am able to touch
a new file on the mergerfs mount inside the container if I do docker-compose exec deluge bash
and su abc
though...
I was able to fix this by removing the direct_io
argument to mergerfs and adding cache.files=full
(not sure if that was necessary since it defaults to cache.files=libfuse
when direct_io
isn't set).
Thanks @brott8 for pointing me in the right direction. :)
I can confirm removing direct_io from mergerfs works
can you share your whole options ? I replaced direct_io for cache.files=full ? Torrents can be now added but does not start downloading. Pretty sure this is one of my option that screw things up
Expected Behavior
Torrents shouldn't be stuck with an error message and should download normally.
Current Behavior
All torrents are errrored out with "No such device". Same issue as reported here: https://github.com/linuxserver/docker-deluge/pull/135#issuecomment-1054899503
The exact same config and setup works with version-2.0.5-0202202181752ubuntu20.04.1 but not version-2.0.5-r0 (latest).
It seems like this PR is the source of the trouble: https://github.com/linuxserver/docker-deluge/pull/135
Steps to Reproduce
Not sure what's triggering this so hard to say. Contents of
core.conf
:I'm using a few plugins; PIAPortPlugin is the only one that's not included with Deluge.
Environment
OS: Ubuntu 20.04.3 LTS CPU architecture: x86_64
Command used to create docker container (run/create/compose/screenshot)
Docker Compose:
Docker logs