-
Move all Process runs to the Backend
Agree with this - I'm trying to run Docker Safe New Permissions on millions of files and folders. I have to keep that browser window open and hope it doesn't crash - I thought running it on Unraid UI Firefox on the box itself was a great idea... then the browser tab crashed over night. (Being able to run it on individual shares, drives or folders would be amazing too, but I realise that's an ask for the plugin developer that's already been made before).
-
[Support] binhex - Deluge
I ended up going with delugevpn and no longer have the issue of the daemon going inaccessible - it's not too hard to setup any vpn for binhex-delugevpn and you can copy over your torrent states with a bit of Googling. It's been working perfectly and I like that it's a bit less complicated (therefore prone for something to go wrong) setup than using another container's network. Honestly, I spent days on this, searching and trying different things, and ultimately the above was the right solution.
-
node started following [Support] binhex - Deluge
-
[Support] binhex - Deluge
binhex-deluge has recently "stopped working" for me every 24 hours or so. By that I mean my the daemon appears offline to my Windows Deluge client and the webUI doesn't load - both work after a container restart. I don't know a way to check if it's still seeding or partially still running in some manner, but the container hasn't stopped according to the Unraid UI. The last four lines of the supervisord.log are consistently something like this when this happens: 2023-07-22 16:30:55,639 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22770150224528 for <Subprocess at 22770134306832 with name deluge-script in state RUNNING> (stdout)> 2023-07-22 16:30:55,658 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22770149763984 for <Subprocess at 22770134306832 with name deluge-script in state RUNNING> (stderr)> 2023-07-22 16:30:55,682 INFO exited: deluge-script (exit status 0; expected) 2023-07-22 16:30:55,688 DEBG received SIGCHLD indicating a child quit From searching here and other places, I've so far tried: - Switching from the nordlynx container to Gluetun for nordvpn wireguard as some comments said it could be VPN related. - Removing a reference to user0/download that I previously added in the container config in case that was messing with things - Deleted perms.txt and let it rebuild. Any help resolving this appreciated - I COULD just create a userscript to reboot the container nightly, but it seems wiser to solve it properly.
-
node started following (6.11.3) Connecting via SMB shows no shares
-
(6.11.3) Connecting via SMB shows no shares
After hours of unsuccessfully troubleshooting why connecting to Unraid by server name or IP from Windows via SMB in Unraid 6.11.3 wouldn't show any share folders, I rolled back to 6.11.1 (to avoid the drive formatting bug I also encountered in 6.11.2) and the folders instantly showed up again in Windows. Shares were all set to SMB Export and Public. Windows Credentials had a dedicated non-root Unraid user/pass configured. I've attached my diagnostics.zip from my 6.11.1 (-332.zip) and 6.11.3 (-1354.zip) installs. Let me know any other info I can provide to help. unraid-diagnostics-20221112-1332.zip unraid-diagnostics-20221112-1354.zip
node
Members
-
Joined
-
Last visited