The_Doctor

Just ran into an odd issue that took me a bit to find. Ended up being permissions on my download dir were changed somehow and deluge did not have permissions to use it. It would start fine, files would be queued up, they would look like they started to download, then they would just stop with no error. Searched logs and was unable to find anything. I ended up installing binhex-qbittorrentvpn and right away a file went into error state, and the log showed why. In the future, where am I missing logs that would show issues like this or why a file goes into error state. Example from binhex-qbittorrentvpn: (W) 2024-03-05T19:43:01 - File error alert. Torrent: "XYZ". File: "/data/Downloading/XYZ". Reason: "XYZ file_open (/data/Downloading/XYZ) error: Permission denied"

I might have missed it, but any way of adding in a un/select all on the targets? When using scatter on the old version, it would auto pick all targets but the one that was being used as the source. With large arrays it can be tedious to pick all targets. I understand that the auto select all could also be the opposite needs for some, so a select all /un select all, might be a good option?

same

Good news, it took some time, but finally finished 31-12-2019 02:32 Fix Common Problems Extended Tests Completed Errors Found warning 29-12-2019 20:05 Fix Common Problems Extended Tests Beginning normal

Thank you for looking into it. The only recent changes on the server was a chassis/hardware change. I can’t recall the last time I ran an extended test before that, more than a few months. Not sure if that would change anything with the working of the application. One would think that a uninstall, reinstall would correct that if there was? Everything else is working correctly that I can tell. I can try to swap back an test if you think it’s worth the effort.

Thank you for the help so far. Any idea where to go from here? Any debug I can enable for further review?

requested output: after about 24 hours. ps -aux | grep extendedTest root 2874 18.7 0.0 100952 24420 ? S Dec25 286:18 /usr/bin/php /usr/local/emhttp/plugins/fix.common.problems/scripts/extendedTest.php root 3263 0.0 0.0 3912 2248 pts/1 S+ 12:06 0:00 grep extendedTest Tail of log: /tmp/fix.common.problems# tail -f extendedLog <tt><b>The&nbsp;following&nbsp;user&nbsp;shares&nbsp;will&nbsp;be&nbsp;excluded&nbsp;from&nbsp;the&nbsp;permissions&nbsp;tests:</b><br><br></tt><tt>/mnt/user/appdata<br></tt><tt><br></tt><tt>Processing&nbsp;/mnt/user/appdata<br></tt> I did however notice if I stop the array, it will force finish the job, with the below results (removed some share names): The following user shares will be excluded from the permissions tests: /mnt/user/appdata Processing /mnt/user/appdata Processing /mnt/user/ Processing /mnt/user/ Processing /mnt/user/ Processing /mnt/user/ISOs Processing /mnt/user/ Processing /mnt/user/ Processing /mnt/user/ Processing /mnt/user/ Processing /mnt/user/ Processing /mnt/user/ Processing /mnt/user/ Processing /mnt/user/ Processing /mnt/user/ Processing /mnt/user/ Processing /mnt/user/Programs Processing /mnt/user/Server_Backup Processing /mnt/user/ Processing /mnt/user/ Processing /mnt/user/system Processing /mnt/user/ The following files / folders may not be accessible to the users allowed via each Share's SMB settings. This is often caused by wrong permissions being used on new downloads / copies by CouchPotato, Sonarr, and the like: /mnt/user/BACKUP root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/ISOs root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/Programs root/root (/) 0 /mnt/user/Server_Backup root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/ root/root (/) 0 /mnt/user/system root/root (/) 0 /mnt/user/ root/root (/) 0

Extended test not completing and stuck on appdata. I let it go for 24 hours before removing/reboot/re-installing and trying again today. Is there a way to force stop the test, and or get any more information on what it is doing? The tail and system log show no more than what the "status" shows on the GUI. TIA extendedLog: /tmp/fix.common.problems# tail -f extendedLog <tt><b>The&nbsp;following&nbsp;user&nbsp;shares&nbsp;will&nbsp;be&nbsp;excluded&nbsp;from&nbsp;the&nbsp;permissions&nbsp;tests:</b><br><br></tt><tt>/mnt/user/appdata<br></tt><tt><br></tt><tt>Processing&nbsp;/mnt/user/appdata<br></tt> System log: Dec 23 11:19:48 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 11:22:11 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 11:24:58 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 11:30:08 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 11:33:22 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 11:40:27 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 11:44:31 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 11:52:51 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 11:57:12 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 12:02:50 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 12:03:41 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 12:10:15 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 12:17:44 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 12:40:11 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 12:40:16 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 13:08:03 Tardis root: Fix Common Problems Version 2019.11.22 Dec 23 15:17:29 Tardis root: Fix Common Problems Version 2019.11.22

Master Version: Not sure what is going on, just updated, and now it crashes without much in the logs. Debug mask set to true or false comes up with same logs I will install and test dev, as I no longer see a master version, only 2 dev versions available. < ___. .__ .__ \_ |__ |__| ____ | |__ ____ ___ ___ | __ \| |/ \| | \_/ __ \\ \/ / | \_\ \ | | \ Y \ ___/ > < |___ /__|___| /___| /\___ >__/\_ \ \/ \/ \/ \/ \/ https://hub.docker.com/u/binhex/ 2019-12-04 17:03:37.527209 [info] System information Linux 642928f489f4 5.3.6-Unraid #2 SMP Wed Oct 16 14:28:06 PDT 2019 x86_64 GNU/Linux 2019-12-04 17:03:37.565416 [info] PUID defined as '99' 2019-12-04 17:03:37.760181 [info] PGID defined as '100' 2019-12-04 17:03:38.047748 [info] UMASK defined as '000' 2019-12-04 17:03:38.082860 [info] Permissions already set for volume mappings 2019-12-04 17:03:38.125948 [info] DELUGE_DAEMON_LOG_LEVEL not defined,(via -e DELUGE_DAEMON_LOG_LEVEL), defaulting to 'info' 2019-12-04 17:03:38.160930 [info] DELUGE_WEB_LOG_LEVEL not defined,(via -e DELUGE_WEB_LOG_LEVEL), defaulting to 'info' 2019-12-04 17:03:38.197591 [info] VPN_ENABLED defined as 'yes' 2019-12-04 17:03:38.245688 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/** >

- Looks like you might have solved an issue I brought up a few pages ago. Seems 2.4.7 openVPN is not playing nice with my vpn provider. Issue: when VPN set to write UDP: Operation not permitted (code=1) Not working Binhex DelugeVPN: Sun Sep 29 10:30:24 2019 OpenVPN 2.4.7 [git:makepkg/2b8aec62d5db2c17+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019 Working Flexget delugeVPN: Sat Sep 21 15:27:14 2019 OpenVPN 2.4.0 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Dec 28 2016 Also working OpenVPN client app: openvpnclient 2019.02.09 Update of OpenVPN packages to 2.4.6-2

@binhex Having same issue has someone in this thread several pages back. The issue "write UDP: Operation not permitted (code=1)" that appears to be isolated to your dockers. I tried your: binhex delugevpn binhex qbittorrentvpn Both come out with write UDP: Operation not permitted (code=1) I tried delugevpn-flexget from paulpoco/arch-delugevpn using the same openvpn file, and it works just fine. Please let me know what I can give you to help sort this out.

I do not have it enabled, and my settings are the same as yours, just a different 10 network. I did play around with it, I do see "br0 Custom" in the docker container, but when enabled, and set with an IP. It would work for a bit then stop responding. Log shows connection timeout, or something along the lines. I tried several versions of plex containers, and even set to "Host" some would just not work after the 1st reboot. Right not I am running only 1 Plex container and its the linuxserver/plex version set with HOST network. Not sure what happened, during the upgrade, but I am unable to get br0 to work on any new container setup. Right now, I am tired of rebuilding a plex DB all the time so I have left it as only running one Prod Plex server for now. I know you can transfer the Plex DB over manually to a new server, but seems like it works, then after 1st reboot, those DB files are dead, and no longer work causing the container to not even fully come up. Only way to get the same container to work again would be to remove the container, and the appdata folder completely and install again. Maybe there is a permission issue on 6.6 as well?

Ran into this same issue. I had 2 plex dockers running, one for test, and one for Prod. My Prod one used br0 and a /24 IP and was set for use from outside. I thought something broke on the docker, but it turns out if i switch to use Host it worked just fine, but I cant do that with another plex docker using the same settings.

Apologies, I see it now in the pack, I overlooked it.

Any luck on finding findutils, so we can get updatedb and locate?