ShadyDeth

For those wanting to stay on updated versions of bixhex releases, I see he did release libtorrentv1 versions of his apps. Change your repo's to the following. binhex/arch-qbittorrentvpn:libtorrentv1 binhex/arch-delugevpn:libtorrentv1

Just noticed I am also have the "Operation not Permitted" issue happening. @lnxd

Yes that is correct. I myself have switched from deluge to that version and It's been running fine for me. Have you ran diagnostics or logged your syslog to see if you're getting the same crash error or if it's something different causing the crash?

Linuxserver provides an up to date version of qbittorrent with libtorrent V1, which will stop the issue. In the "Repository" section put: lscr.io/linuxserver/qbittorrent:libtorrentv1

I have had zero issues running this version since my posts were made.

My linuxserver/deluge:2.1.1-r3-ls179 is seeding just fine through PrivoxyVPN. Deluge docker settings PrivoxyVPN docker settings. I did change the PIA Wireguard settings to a network location closer to me. And my Deluge network settings and proof of seeding. (Pls dont judge my horrible ISP upload speeds)

This is probably no where near the right way to do it, but this is how I got it to work. On the deluge container I removed all the port settings, and in the webui network settings I set the inbound and outbound ports to random. And for Privoxy I added Deluge's webui port to Key13, Key14 and added a new port setting for deluge and then it started working. If you want to use specific ports, I would assume you add them to Key13 and Key14, and set them in the deluge webui.

Hey there @pr85 Assuming you want to stay on Deluge and have the VPN option, easiest workaround I found was to install the linuxserver.io Deluge 2.1.1 libtorrent v1 @JesterEE posted about. And then I also installed binhex-privoxyvpn along side that since it has all the same VPN options his binhex-delugevpn has. Then all you do is route the Deluge container's network through binhex-privoxyvpn. Easier said than done if its your first time doing that. I followed this guide and got it working after a bit of user struggle. If you need more help with that let me know. One thing I will say is make sure you have Privoxy running first or else Deluge will use your IP and not the VPN IP. Not sure why when it's network is routed through the Privoxy container. I set a start wait on deluge (Docker > Advanced View > fill in the wait on autostart) to fix this on any reboots. Also if you're running "CA Backup / Restore Appdata" that messes with this whole set up since it restarts all your docker containers at the same time when its doing its back up, and deluge has used my ip every time instead of the vpn. So I've disabled it for now.

So I ran the commands @binhex posted for libtorrent/transparent hugepages issue on the day he posted it. Rebooted and made sure they were still disabled. Well, today I crashed again. Same issue, dead docker, unresponsive unraid webgui. Still running the latest version of binhex-delugevpn. Made sure to capture that transparent hugepages was still disabled before rebooting. Going to downgrade to a version with v1 libtorrent since we know the issue is in v2.

Well, my iotop logging test has left me with nothing to show for it. Got the crash But my logging script stopped logging all info 6 minutes before that. Everything here is normal info that was logged numerous times throughout the logging. Got a question for you @sundown. I would assume you're using the vpn function of that container. Are you using openvpn or wireguard? Also @JesterEE, @CiscoCoreX, @III_D and anyone else reading this having the issue, could you give a little more info on your torrent container and whether you're using the built in vpn (openvpn or wireguard) or using the "VPN Manager" built into Unraid if using a vpn at all. Just trying to look at changes from 6.10.3 to 6.11.x. There were wireguard changes, but I use built in version in "binhex-delugevpn", so im not sure it has anything to do with that. Also the docker version was upgraded from 20.10.14 to 20.10.17 in 6.11.0 and 20.10.18 in 6.11.1. Is there anyway to downgrade to docker 20.10.14 and for testing? Would taking the docker.img from /mnt/user/system/docker/docker.img on 6.10.3 and copying it to 6.11.x work?

The command to reboot is: /sbin/reboot As for testing results. I ran Fio for the 30mins to test it and see how it works. Test ran fine. Next I decided to run it for a 6hr test. It completed without any issue. Both times I used options posted above and only changed the runtime. But in typical fashion, randomly today when doing nothing besides seeding, had a crash on 6.11.3. Syslog shows the typical info we already know. As for more testing. I saw a package in NerdPack/NerdTools called iotop. If you know what top/htop is, its that for io disk info. Been messing with that and logging the output by running a script with the User Scripts plugin. It's basically spammed with deluge (my tor app of choice), but hoping to catch something with it when I start doing real testing with it. I'm not the best linux user so any help is welcome with the command. Here's what I'm current running. Found here. The output is spammed with deluge since im seeding. But I'm not sure I want to exclude that from being logged. But if I wanted to exclude the deluge info, how would I go about doing that.

Not sure you're having the same issue that those of us in this post are having. Your Call Trace would have to look something like the one in @JorgeB original post. Most all people rolling back to 6.10.3 seem to have their issues fixed once downgraded. Are you logging your syslog to your Flash? That should be catching everything so the reboot doesn't wipe any info of what's happening. I am also using Ryzen but I doubt that's the issue since in the first post it lists a Ryzen and Intel system. I did rollback to 6.10.3 but I have upgraded to 6.11.2 to see if the issue still exists in this version also. All plugins installed on the list.

Just had another crash. This is what I came back to after a reboot. Too early in the morning to fix this. But once I get it fixed. I think im going to remove Unassigned Devices and see how long I can go without a crash. Maybe I didn't give it enough time the first go around. EDIT: Looks like I got a bad SFF 8087 TO 4 x SATA cable. Ordered some new ones. Testing on hold until the new ones arrive.

Since disabling the 7 plugins that were found to be in common with most users having this issue, I let my server run for 24hrs with no issues before reinstalling each plugin 1 by 1 and letting the server run for a full 24hrs before installing another one. Oct 12th: Full 24hrs with none of the 7 plugins installed Oct 13th: Reinstalled Community Applications (community.applications.plg). Ran full 24hrs, no issues. Oct 14th: Reinstalled CA Backup / Restore Appdata (ca.backup2.plg). Ran full 24hrs, no issues. Oct 15th: Reinstalled Fix Common Problems (fix.common.problems.plg). Ran full 24hrs, no issues. Oct 16th: Reinstalled Unassigned Devices (unassigned.devices.plg). Installed at 1pm EST on the 16th, server crashed at 10am EST on Oct 17th. This could just be a coincidence and be one of the other plugins causing the problem, But it's looking like it might be Unassigned Devices. I have one 500GB ssd on Unassigned Devices for saving downloaded torrents onto via binhex-delugevpn. Running binhex-delugevpn using wireguard vpn option. The "Pre-allocate disk space" was turned off but I have now enabled it to see if that might help the issue somehow from other posts above. Just for testing purposes I'm going to uninstall the 3 plugins I installed before Unassigned Devices to see if I get another crash within a few days time. Including my diagnostics from the crash today. impulse-diagnostics-20221017-1545.zip

Checking in. It's been over 24hrs since I removed 7 plugins in the top post for testing. I have been running my machine as I normally would besides my torrents saving to the array instead of an unassigned device. Haven't had any crashes yet like I was having before. My dockers are using macvlan, and I wont be changing to ipvlan just to keep my machine the same has it has been since starting the plugin test. Will continue with updated info when needed.