Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About 7thSon

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I've rebooted the host multiple times since this issue arose... UPDATE: Christ almighty.... I found the problem.... the disk was FULL! *facepalm*
  2. Yeah, writing inside the container to completed/incompleted works. Hmm... what the hell has happened with my mount of this disk... I tried going into /mnt/ntfs1/downloads on my host with my user that has the same UID/GUID as the container (1000:100), and running "touch test" works just fine. Looking in /etc/passwd in the container I can see that "nobody" is set up correctly as 1000:100. I also did "su nobody" in the container, went into the downloads folder and tried "echo 'write ok' > test", this also works just fine. What else can I check to find out why the container user isn't able to write to the disk/folder?
  3. No, I'm not running this under Unraid at all, just in a docker container on an arch host. I've never had issues with writing to the disk in any way.
  4. Writing to /mnt/ntfs1/Downloads/test works fine, the test file is created without any issues.
  5. Did you have any further input on my lack of connectivity/traffic discussed on the previous page? I'm completely stuck with it.
  6. The download folder is not wrong. Below is my docker-compose file. version: "3.2" services: deluge: restart: unless-stopped image: binhex/arch-delugevpn container_name: deluge cap_add: - NET_ADMIN devices: - /dev/net/tun ports: - 8112:8112 - 8118:8118 - 58746:58746 # incoming port - 58846:58846 environment: PUID: "1000" PGID: "100" VPN_ENABLED: "yes" VPN_USER: "redacted" VPN_PASS: "redacted" VPN_PROV: "custom" STRICT_PORT_FORWARD: "no" ENABLE_PRIVOXY: "yes" LAN_NETWORK: "" DELUGE_DAEMON_LOG_LEVEL: "info" DELUGE_WEB_LOG_LEVEL: "info" DEBUG: "true" UMASK: "000" volumes: - /home/user/.config/deluge/:/config - /mnt/ntfs1/Downloads:/mnt/ntfs1/Downloads - /etc/localtime:/etc/localtime:ro sysctls: net.ipv6.conf.all.disable_ipv6: 0
  7. Here's a screenshot of my folder settings:
  8. yeah I have the download folder set, I don't use the incomplete folder. tried applying it in the ui again, but there's no difference.
  9. I attached the log from deluge with debug enabled. deluge.log
  10. Roughly a week back my delugevpn container stopped receiving traffic completely. Looking in the logs I can't find anything out of the ordinary, but when starting the container the pending downloads I have seem to start for like a second, then they all drop down to 0kb/s and stop there. How should I start to troubleshoot this?
  11. Could we sort this out in PM, I'm also using a reverse proxy? I just need to see how you formatted your credentials etc so I can match my input to the app and the way I run rTorrent?
  12. Does anyone have a working setup of rTorrent in the nzb360 app currently? It used to work for me, and I'm unsure of what's causing me to not be able to log in, but I'm thinking it might be the username/password settings for the container.
  13. Setting VPN_ENABLED=no makes no difference. And how does VPN even affect the ability to connect to the deluge daemon? I just renamed my core.conf to core.conf.old and restarted deluge so it recreated the file, and now I can connect again. I recall this happening before, somehow the core.conf file get corrupted and I can't connect to the daemon.
  14. Have there been some breaking updates to the container in regards to connecting to the daemon? I can't connect using either the deluge-console ("deluge-console -d localhost -p 58846 -U user -P password"), or the desktop client (2.0.4.dev23). I've been able to successfully connect to the daemon up until about a week ago. The only new error I've seen is the "ngettext" issue from python, but that seems unlikely to be the source of this problem.
  15. Yeah, it works again with that fix applied. Thanks.