clovek1

Upgrading Deluge to new version without any compatible client for Windows was a very bad idea ... I can't even access the WebUI. Only Transdrone from my phone works now. Edit: The WebUI works after deleting manually the web.conf

As this seem to be the correct thread i am reporting here a LinuxServer.io Deluge docker problem. After invoking unRaid mover the Deluge docker is inaccessible by Deluge client. Deleting the content of /mnt/cache/appdata/deluge/state/ solves the problem (but breaks all seeds and downloads). The same problem doesn't occur with Deluge 3.1.11 from needo (using the same configuration in /mnt/cache/appdata/deluge/). Reinstalling LinuxServer.io Deluge and deleting the original image doesn't help. More details in the post below (and all following posts in the corresponding thread): http://lime-technology.com/forum/index.php?topic=42092.msg505964#msg505964 Update1: torrent filenames causing the problem contain special characters like '_','-','=' and '%' (e.g. [xxT]Xxxxx_(1999)(XX)[1080p]_=_XXXX_91%.torrent) the Deluge 3.1.11 log file contains ERRORs related to the filename (Deluge 3.1.13 doesn't complain): [ERROR ] 17:47:31 autoadd:80 Unable to auto add torrent due to improper filename encoding: 'ascii' codec can't decode byte 0xc4 in position 26: ordinal not in range(128) [ERROR ] 17:47:31 autoadd:80 Unable to auto add torrent due to improper filename encoding: 'ascii' codec can't decode byte 0xe2 in position 43: ordinal not in range(128) [ERROR ] 17:47:31 autoadd:80 Unable to auto add torrent due to improper filename encoding: 'ascii' codec can't decode byte 0xc4 in position 8: ordinal not in range(128) [ERROR ] 17:47:31 autoadd:80 Unable to auto add torrent due to improper filename encoding: 'ascii' codec can't decode byte 0xe2 in position 13: ordinal not in range(128) [ERROR ] 17:47:31 autoadd:80 Unable to auto add torrent due to improper filename encoding: 'ascii' codec can't decode byte 0xc3 in position 31: ordinal not in range(128) [ERROR ] 17:47:31 autoadd:80 Unable to auto add torrent due to improper filename encoding: 'ascii' codec can't decode byte 0xc4 in position 28: ordinal not in range(128) [ERROR ] 17:47:31 autoadd:80 Unable to auto add torrent due to improper filename encoding: 'ascii' codec can't decode byte 0xc4 in position 28: ordinal not in range(128) [ERROR ] 17:47:31 autoadd:80 Unable to auto add torrent due to improper filename encoding: 'ascii' codec can't decode byte 0xc4 in position 33: ordinal not in range(128) Update2: binhex-deluge 3.1.13 is working fine with the same torrents. The error doesn't seem to be Deluge 3.1.13 related and the filenames don't seem to cause the error.

Technically, it would be this: http://lime-technology.com/forum/index.php?topic=43430.0 (I think CHBMB just missed his morning coffee ) You can get all the relevant support threads either through CA, or via the Alls Apps Support Thread sticky Oh, please accept my apology. If any moderator can move my Deluge related posts to the appropriate thread, it would be nice. Continuing here: http://lime-technology.com/forum/index.php?topic=43430.msg505975#msg505975

as the deluge complained about 2 docker containers using the same configuration directory, i removedthe needo/deluge docker (including image). the resulting deluge.log file is short: [iNFO ] 16:54:48 configmanager:70 Setting config directory to: /config [iNFO ] 16:54:48 daemon:124 Deluge daemon 1.3.13 [iNFO ] 16:54:48 configmanager:70 Setting config directory to: /config [iNFO ] 16:54:48 core:85 Starting libtorrent 1.0.9.0 session.. [iNFO ] 16:54:48 rpcserver:367 Starting DelugeRPC server :58846 [WARNING ] 16:54:48 preferencesmanager:496 Unable to find GeoIP database file! [iNFO ] 16:54:48 core:97 *** Start Label plugin *** [iNFO ] 16:54:48 pluginmanagerbase:158 Plugin Label enabled.. [iNFO ] 16:54:48 pluginmanagerbase:158 Plugin Blocklist enabled.. [iNFO ] 16:54:48 torrentmanager:650 Successfully loaded state file: /config/state/torrents.state [iNFO ] 16:54:48 torrentmanager:779 Successfully loaded fastresume file: /config/state/torrents.fastresume I am using a https connection to the Deluge server (selfsigned certificate). Deleting the content of /mnt/cache/appdata/deluge/state/ directory solves the Deluge server connection problem. But it deletes all my torrent progress etc.

Isn't this the support thread for LinuxServer.io Deluge container? The problems seems to be unRaid+Mover+Docker+Deluge 3.1.13 specific. I am quite not sure if anyone in Deluge support would know what an unRaid mover is and how it works with the Deluge.

screenshots continuing.

attaching more screenshots

Errrr..... thanks. It doesn't really help us to get to the bottom of any problems though does it? And seeing as you've never actually posted in the deluge support thread reporting anything I guess I can only apologise that our psychic powers have failed. needo's image also hasn't been updated in over a year, but I've heard he's got a better head of hair than me though... My suggestion would be to continue using needo's image then. you are right, the needos docker is version 1.3.11 and yours is 1.3.13. do you have any suggestion what information may help you to locate the problem ? Was ours a completely fresh pull with it's own appdata, not a migration to/from needo? EXACTLY how is the container setup, screenshots or your docker run command are useful, including any setup you've done within deluge itself, inc plugins etc Basically, to fix issues we need to know at least there's a problem and secondly, how to reproduce it. Oh, and posting in the support thread for the app is a good start as well. Thanks for the fast reply. The actions i have performed are: - stop Needo/Deluge server - remove LinuxServer.io/Deluge (also remove image - checked in) through unRaid web interface. - installed LinuxServer.io/Deluge - configured the download directory to /mnt/user/Media/download/ - reused the existing deluge configuration in /mnt/user/appdata/deluge/ - unraid->Docker shows in web interface LinuxServer.io/Deluge being started - Deluge web interface at https://192.168.0.100:8112 can't connect to the server. status = Offline screenshots are attached and numbered chronologically (1-4)

Errrr..... thanks. It doesn't really help us to get to the bottom of any problems though does it? And seeing as you've never actually posted in the deluge support thread reporting anything I guess I can only apologise that our psychic powers have failed. needo's image also hasn't been updated in over a year, but I've heard he's got a better head of hair than me though... My suggestion would be to continue using needo's image then. you are right, the needos docker is version 1.3.11 and yours is 1.3.13. do you have any suggestion what information may help you to locate the problem ?

This version of Deluge docker failed to operate each time the unraid mover is invoked. needo's version of Deluge docker works with the same docker configuration flawlessly.

I have expirienced file permission problems with latest Transmission (build Id Status Created Date Last Updated bw24et6ti54xd7tmgxhbwnd Finished 2014-09-06 05:57:53 2014-09-06 06:04:44) docker in Unraid 6rc3. the umask:18 in settings.json causes write/delete problems for all share users except "nobody" and of course "root". This happens e.g. if the unraid share has private/secure security and configured more users, then just the root. umask: 73 fixed the problem. for more details see my post: http://lime-technology.com/forum/index.php?topic=40300.0

I finally figured out the solution: in file: appdata/Transmission/settings.json change the: umask: 18 to: umask: 73 this will save the downloaded files with rw-rw-rw- permissions. Note: -you have to stop the Transmission in Docker prior to editing the settings.json file. Otherwise your changes are lost. - to fix permissions for allready downloaded files run the "chmod -R 666 *" in your Download directory from a console (e.g. putty or any telnet client you prefer).

The Transmission (Docker) is creating files with permissions: -rw-r--r-- therefore only the file owner (user: nobody) can move/delete the files. Previous Transmission plugin (non Docker) was creating the files with permissions: -rw-rw-rw- I am accessing the files with user:somebodyelse, therefore i can only read all the downloaded files in the share, but not delete or modify them. Is there any simple way to fix this (except running chmod from command line) ?