Cannot Connect to Deluge Daemon from Remote Machine

[Zoot]

I'm having an issue connecting to the Deluge Daemon on my home server. It's a shame since I really like running Deluge as a daemon on my server. It's only since I've upgraded the server's hardware, my old server system functioned just fine.

My server runs Windows and I have Deluge set up as a service via NSSM (with deluged-debug.exe & deluge-web-debug.exe) just as is outlined here in the instructions.
https://dev.deluge-torrent.org/wiki/Use ... MS_Windows

The Daemon is running. I can connect to it just fine to the daemon via 127.0.0.1:58846 on the Server system, but I can't connect to the Daemon running on the Server via the Thin Client on the regular desktop.

I can also connect just fine to Web UI on both the server via http://127.0.0.1:8112 and my regular desktop (also running Windows) via http://192.168.0.190:8112 (static IP of my server).

I have a username & password defined in C:\config_location\auth and I have allow_remote set to "true" in C:\config_location\core.conf

I have rules defined in Windows Firewall to allow connections via Port 58846 & 8112 also.

Does anyone have any ideas? This seems to be a common enough issue.

If I try and use deluge-console.exe on the Client Desktop, I get the following:

Code: Select all

C:\Program Files (x86)\Deluge>deluge-console connect 192.168.0.190:58846 mark mark
Failed to connect to 192.168.0.190:58846 with reason: No connection could be made because the target machine actively refused it.

[Zoot]

My god, I feel quite stupid now...

I've solved the above issue, minutes after posting it. However this has caused me quite a bit of frustration over the last few days after going around in circles.

I double checked the allow_remote setting in the C:\config_location\core.conf file, and I noticed that it would always default back to "false".

In other words, I would stop the services (deluged-debug.exe & deluge-web-debug.exe) via NSSM. Manually set allow_remote to "true" in C:\config_location via a text editor, save the changes, close the file, and then restart the services (deluged-debug.exe & deluge-web-debug.exe) via NSSM again. Each time the allow_remote setting would default back to "false".

The solution... Set the allow remote connections via the Deluge thin-client GUI connected to 127.0.0.1:58846 on the server.

and now... I'm greeted with a lovely green circle on the remote machine upon bringing up the connection manager.

Hopefully this will be of use to someone who comes searching with the same issue.

Here:

deluge_forum_post.png (24.13 KiB) Viewed 21972 times

deluge_post2.png (15.48 KiB) Viewed 21972 times

[shamael]

Hi,

The core.conf file used is located in the appdata folder of the user launching the application, check in %AppData%\deluge on your computer.
Maybe your setup is right but it's a very common mistake. Are you sure the file in C:\config_location\core.conf file is the one used?
(check the access/modification time). It will explain why you faced the issue.

[Zoot]

Interestingly the core.conf file in the Appdata folder has an earlier modification time, and the allow_remote setting is set to "False" so I'm guessing the C:\config_location\core.conf file is the one being used, otherwise I wouldn't be able to connect to the Daemon at all.

It seems the GUI basically overrode the core.conf each time it was launched.

[shamael]

Stop Deluge, rename C:\config_location\core.conf to .old, adapt the one in appdata.
What's going on this way?

The default location is appdata, but you can point the service or application startup config to whatever suits you. Except if you do so, the appdata is the right one. Anyway the above test will enlighten the thing a bit maybe

[Zoot]

So... if I rename the C:\config_location\core.conf to .old, and adapt the one in %APPDATA%, it makes no difference to the Daemon.

A new C:\config_location\core.conf is created with the allow_remote set to "false" upon starting the Daemon via NSSM again. If I stop the service, manually set the allow_remote back to "true" via a Text Editor, and restart the service, I can connect to it just fine again from the remote machine.

That's what I tried initally but it wasn't working for me. Not sure what's going on... but it's working just fine once more.