jraid

I was having similar errors and the GUI would go down, seems to nginx or php failing within the container itself. I found by restarting php-fpm the GUI starts working again: /usr/bin/php-fpm --pid '/home/nobody/php-fpm.pid'

Is there a way to tell what commit version of rutorrent has been pulled? I posted a question above trying to figure out if a fix is included in 3.9 or only the beta.

Having an issue with rutorrent - https://github.com/Novik/ruTorrent/pull/1516 It was fixed in this commit: https://github.com/Novik/ruTorrent/commit/825d56e8b0a2731a8196f9c8af3f732868a66fde Since that is tagged with both: v3.10-beta, v3.9 Does that mean it's not fixed in 3.9? I am seeing the issue in this docker. Any instructions on how to update rutorrent/rtorrent to a beta version?

The UI should save to that file, and read from it on every container start. The error may be somewhere in that interaction, and starting from scratch might help solve it. This would include removing or renaming the file so it's recreated the next time, setting the options in rutorrent, and hopefully they appear in the file and load correctly upon a restart. Not sure why it would only happen some of time if the web user is always the same.

Yeah you should be fine with the default account, it was just a thought as mine broke when I changed users and the default config remained the same. Not sure what your issue is then, but take alook at autotools.dat and see if it matches the GUI settings?

What webuser are you using when logging into rutorrent? I found that the default admin account has different settings than my custom made user account. This admin account is used during container startup, see below and here is the autotools code: https://github.com/Novik/ruTorrent/blob/97d5dc60febb9d8c6e5384a0a0d8fec3e4fa10cf/php/initplugins.php#L122 You can find autotools.dat in this confusing path inside config folder: \rtorrent\rutorrent\share\users\user\settings @binhex I did find a container breaking bug related to the default admin user, when the WEBUI_USER is supplied and this initplugins line : execute = {/bin/bash,-c,/usr/bin/sleep 10s && /usr/bin/php /usr/share/webapps/rutorrent/php/initplugins.php admin &} It's is hardcoded as a default of 'admin' for the webuser, and also in /home/nobody/initplugins.sh uses 'admin'. I'm not sure if it's a container bug or a rutorrent bug, but when that user is non-existent it breaks all downloads as I removed admin from my auth file, previously discussed in this thread. I had removed the default admin account for security, and found my downloads all would download correctly, then fail when autotools tried to move them with a mysterious error that took a weekend to track down to the above lines. The files would become filled with null bytes after the error, and I am glad I caught it before more files were destroyed.

I agree with removing default credentials. I ended up removing admin manually from my config file. Also the edit to the readme file here: https://github.com/binhex/arch-rtorrentvpn/commit/487dac431e87fc67d8e0106217b20af1cfeba017#diff-04c6e90faac2675aa89e2176d2eec7d8 is confusing as you used <> for variable holders, which are normally inside of markdown code blocks (`), but in this case they are not. To the casual viewer, it looks like there is no username or password when viewing the readme, but in reality it's either the default or custom set creds. I don't see the default mentioned in the readme either. Perhaps change usage of <> to [] or more judicious use of code blocks?

Yeah I know that's a bit extreme :p, you can set it something lower, but the original limit of 128GB is now no longer out of the question. While you're updating the settings file I also noticed 2 small inconsistencies: is in there twice (both commented out) This comment didn't get updated when the encryption options were:

I spent a few hours tracking down this (outdated) bug: https://github.com/rakshasa/rtorrent/issues/472 The issue materialized as a torrent always stuck in the "queued" state, and could never start after multiple attempts. There weren't any useful debug log messages that I could find, just a stuck torrent. After tmux attaching to the rtorrent process, I found the rtorrent log, and eventually found the setting to fix it (which appears to be fixed in the unstable branch back in 2016😞 system.file.max_size.set = 3000G This would be good to include as commented out default rtorrent.rc It would also be nice if more errors were surfaced or a guide on raising log verbosity: log.open_file = "rtorrentdbg", /config/log/rtorrent_debug.log log.add_output = "debug", "rtorrentdbg"

I searched and didn't see any previous discussion, but does the HTTPS/SSL port not work? I noticed that Sonarr is configured to run HTTPS on 9898, which doesn't match the default exposed container port of 9897. But even after getting those to match, I can't access sonarr over SSL. Before I look more into https://github.com/Sonarr/Sonarr/wiki/SSL I thought I'd ask here.

I've having trouble seeding, after creating a new rutorrent web user via the provided createuser.sh script. I can finish torrents successfully but after they hash check and get moved, they enter a 0%, "Download registered as completed, but hash check returned unfinished chunks." state. I assume it's a permission error, I deleted the default web user - but the folder permissions look okay and I don't know why the web user is affecting anything on the file system. Any tips? Any log files to check for rtorrent? I don't see anything in supervisor log. Edit: well now I tried to install the LogOff plugin and got a PHP error, followed by deleting the plugin's folder (original state) and breaking rutorrent completely: Bad response from server: (200 [parsererror,getplugins]) SyntaxError: expected expression, got ';'