Deluge Forum

The Deluge package for Synology NAS devices has recently been updated to work with the newest version of NAS firmware (DSM 7).

The new version seems to be working for others, but for me when adding a new torrent I get an error regardless of the tracker I use. Two trackers give the "Tracker Status: unspecified system error" message in the status pane, and a third gives "Tracker Status: certificate verify failed".



All the troubleshooting I've found via searching have suggested just installing a local certificate to fix the issue, but I'm not sure how possible that is when Deluge is running from a package (presumably in a container?) like it is on a Synology NAS.

Another guide recommended turning of strict SSL checking, but I can't find an option for that in the WebUI.

Does anyone else recognise this issue?

Hello, I am experiencing the exact same error as the original post. In my case I am getting "Error: unspecified system error"



Hope there is a fix as I was finally happy that Python got updated to 3.10 which allowed Deluge to install on my Synology NAS, and finally get to test it!

Appreciate any help!

Sorry I don't know DSM stuff unfortunetly, and can only say the issue presumably is libtorrent from pypi on linux need an env-var defined to work for https tracker announcing support, more info here: viewtopic.php?t=56093

Anyway, I quickly read-up on how add env-var or if even possible, on synology DSM 7, and seemingly there's a bug with this for a long time and still not fixed. Various workarounds posted though, but as said, don't know anything about this sorry. Also, I have no idea if the path for the certificate of openssl is the same as standard path on e.g. debian/ubuntu, so even if can add the env-var then need it set correctly also obviously.

Here's the two threads about env-vars on DSM I skimmed through quickly:

https://github.com/portainer/portainer/issues/5813
https://github.com/portainer/portainer/issues/2423

Last, a bad workaround is to simply disable SSL verification of HTTPS links, so if for some reason wanting accept the risks and do this, then there's instructions for that in top-thread in this post i.e. disabling 'validate_https_trackers' with ltconfig plugin.

Sorry cannot help better with this.

this started happening to me as well for 2 different https trackers on a linux machine. on windows everything works as expected.
@mhertz - do you think it it is something related to deluge or libtorrent?
i'll try to investigate also...

Hi DjLegolas!

Yes I do think libtorrent related, not deluge - specifically if libtorrent gotten from pypi, so pip and not sure if PPA etc, then there where some talk some years ago, or so, about vendoring in openssl, and then need hardcode the ssl cert path, but problem is that this isn't standardized on linux, e.g. debian vs fedora etc, or whatever the examples was originally raised, so was deemed up to end user. Agreed isn't like this on windows, so either is hardcoded correct there as one platform without any disreprencies, or maybe is because of that certifi where() or whatever goes in deluge code ran for windows only, but i'm not really sure if that part, but just throwing out there, but rather think former. Sorry in a rush currently so little badly written maybe. I remember didn't happen if using e.g. the debain package from apt, since presumably there built regularly i.e. non-vendored(static) openssl. I belive that's the upshot. Anyway, is just a single exported env-var from whatever startup shell file at boot needed, so not that big issue, but just need know of-course.

Edit: One older link(there's more if seraching I remember), and sorry I don't know if things have changed and haven't looked into this for a long time honestly, so if errors or I misunderstood something in above, then sorry:

https://github.com/arvidn/libtorrent/issues/6448

Looks like crypto=gcrypt is used under libtorrent's git repo's .github subdir for the linux wheels, but i'm really bad at CI stuff - libtorrent docs mentiones crypto=openssl specifically for also https tracker announcing support(in addition to piece sha1 checking), but I do know it works if adding said env-var to pypi libtorrent regardless, as states announce OK upon such https announcing test. Also, don't understand why dht=off, but again probably me misunderstanding again, but I will check that later(dht support of wheel on linux I mean).

Edit2: Yeah me misunderstanding because dht is available with the linux wheel. Also, the gcrypt thing probbaly wrong, as just found libtorrent/tools/cibuildwheel dir where openssl is build as static *.a libs for linux, so linked in, atleast looks to me, so disregard the red-hearings sorry.

Edit3: I just in case tested libtorrent's py-bindings without deluge in picture, and with repo-provided libtorrent no prob(shared lib openssl), but the pypi provided wheel shows again also here "unspecified system error" upon https tracker announces, and prepending my python script with 'SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt', or exporting it, fixes it. Maybe deluge could just set that env-var on linux, if not defined already, even though path differs in a few distros, but better than nothing(so working for debian based, arch based etc), or check between the various linux usual cert paths firstly, well beginning sound probably little too far fetched and as said, pretty easy to workaround ourself regardless.

Mhertz, thank you for your effort to look into this, praying for Edit4 to come with the news that this will be somehow be fixed

All the best!

Aww you make me feel bad now mate, but really, thanks for your kind post buddy!

I'll post if finding something, but unfortunetly don't hold your breath, because I cannot really troubleshoot this in blind, and tried lookup if I couldn't install synology DSM 7 in a VM and test there, but not possible, well a workaround exist but you need have a NAS firstly, and export it to VM, or something alike.

Anyway, I had a thought about making a deluge plugin that supplied that certificate file and defined the needed env-var to that file(so didn't need know your certificate file location specifically), and also actually did make that yesterday, but problem is it's loaded to late to take effect, so not a fix. I'm thinking maybe to restart the libtorrent session(or core deluge session maybe, dunno) additionally afterwards, though have never did that before honestly, only ever added/changed some params to current lt session at most, but probably is becoming little to advanced for me propperly now unfortunetly, but as said, if succede then will post back of-course.

Btw, after making that plugin I also saw in the deluge-code that certifi's where() function used for windows probably infact is the reason works in windows, as specifically sets that env-var(SSL_CERT_FILE) which I didn't remembered before, as only wen't from memory there - that is loaded from deluge.common, so early enough to work seemingly, in contrary to a plugin.

Hopefully others have ideas of-course too.

Edit: Sorry didn't work by restarting libtorrent/deluge session from my plugin sadly, and I now also realize I completely forgot unexported env-vars aren't propogated out and only inherented by childs, or something of that sorts, so this would'nt work anyways regardless. Then seemingly you possibly can do something from pyopenssl, but problem is that libtorrent don't use that for https announces, but again will post back if finding something, but now i'm pretty much certain this will go nowhere, sorry couldn't help.

Edit2: Sorry still nothing, but just quick last note about you guys(synology DSM users) could also instead install deluge manually in docker, which doesn't have this issue, guide here: https://mariushosting.com/how-to-instal ... ology-nas/. I think you need add extra line of '-p 58846:58846 \' to the docker install script on said guide, if wanting use GTK-UI to connect to it(thinclient) and not only webU. If wanting stick to regular synology package, then as said can use ltconfig plugin to workaround it, if accepting the security risk.

Thanks for your continued support, which I greatly appreciate!

I am willing to take the security risk, even though I don't know how much of a risk I am taking lol, also I can't use docker because my Synology DSM DS420j Realtek RTD1296 SoC doesn't support docker, so I am stuck with the regular Synology package.

Could I kindly ask for a beginner friendly instruction on how to configure the ltconfig plugin workaround? Many thanks!

You're very welcome mate, but sorry bad news again, can't catch a break(for you guys, I mean) seemingly...

As said i'm complete NAS noob, but I gather if installing the deluge package from synology package center or whatever called, then you get assigned download-folder, but not a (daemon) config-folder from quick readup, for which you then need ssh into if needing such direct access. This is exactly was is needed, because webUI fails installing ltconfig plugin because old bug still not fixed unfortunetly, showing [object filelist] and failing, so need move the plugin into the config-location's plugins subfolder manually and then can enable it in webUI and tick the option needed. It only works if using gtk-UI(i.e. install plugin from preferences > plugins, and not needing manually install to plugins subfolder), and don't know if you can do that.

Here's a thread with a post by meruem for ssh'ing into NAS and find location, just forget the part about editing auth as not needed, and then when knowing location then can scp the ltconfig plugin into there(plugins subfolder) and then enable in webUI, but as you wanted a beginner guide then I kinda guess this is all to complicated, and again i'm sorry for not being able to help.

https://community.synology.com/enu/foru ... ply=291541

The problem is most likely the same problem I reported back in february.

The thread is here:
viewtopic.php?f=8&t=56129

I still believe Libtorrent expects certain things from the OS for the certificate the work.
Synology is basically a Debian Linux.

It would be nice to get this issue sorted once and for all