sundown

Attempting to call, via qbittorrent's "run external command" functionality, an API call from another container (cross-seed) to check if a torrent can be cross seeded at the torrent's completion. The command is: curl -XPOST http://ipaddress:2468/api/webhook --data-urlencode "name=%N". I was hoping that the LAN_ADDRESS worked both inbound and outbound - but appears to only impact incoming requests to qbittorrent (for the UI). Do I have any options?

Could anyone provide additional information here? @H2O_King89 when you mention "tried the docker ip" - are you referring to the docker internal addresses (in my case 172.17.x.x)? To clarify, I'm also attempting to run a Crossseed command (identical to the one quoted here). I have my LAN_NETWORK correctly set to 192.168.2.0/24 and have NO problems reaching the webUI from my home network (192.168.2.x) (not to be confused with the other user's issues here). However running "nc -zv 192.168.2.222 2468" from qbittorrent's command line returns a "connection timeout." Executing this from any of my other dockers succeeds.

Within the last 24hrs, I've had 2 12TB drives either go disabled or throw so many errors to be non-functional. Best I can figure it's just a fluke accident, as I've checked/replaced cables and there have been no other "events" that I have experience with that would have led to this type of failure. So at this point, I'm looking for the best approach to remediating the situation. Based on the logs, I'll assume neither are salvageable/trustworthy, and will have to be replaced. Unfortunately, replacements are still a few days out at this point. I have had prior drives fail, and I've used unbalance to move the files off, remove the drive, rebuilt the array and then add a new drive back into the mix. But with one failed and the other as good as, I'm unsure of the best approach. Any input is appreciated. Screenshot attached and diags as well: unraid-diagnostics-20221130-1825.zip

@binhex Looks like you have a new build of qbittorrent out on the same day that qbittorrent themselves released v4.5.0 with their comment: Assuming your latest build is leveraging their 4.5 release, should those of us on your release be relatively secure in reverting back to "latest"?

60+ hrs here. qbittorrent showing over 8TB up and 12TB down. It would have crashed before now under that type of load. (Not to mention I didn't catch the older version of qbittorrent reset my cache directory and moved over 2TB off of long term storage and on to NVME cache drives, that I had to then move back...). To @JesterEE's point: You'd think some of these large seedbox companies would be shouting from the rooftops that this is broken, but it's almost impossible to find any mention of this issue...

And for users with questions on this, @binhex as already provided you an answer (from https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md)!

At minimum I believe @ShadyDeth mentioned he was using Deluge with this problem. Though it could be related to it also leveraging the libtorrent 2.x libraries in the same manner. I'm not terribly familiar with Deluge unfortunately.

@ShadyDeth Thanks for your continued analysis! Yes, I am using the VPN functionality of the binhex-qbittorrentvpn docker...the wireguard portion. I maintain an OpenVPN container (ich777's OpenVPN-Client) for NZBGet, etc. Additionally, I use the VPN Manager Tunnel's Wireguard so my son at college has access to some sandbox VMs with some oomph behind them. I'm a big fan of researching docker engine changes, and would love to know the answer to this!

Okay all - crashes continue. Logs have stayed the same - but the NATURE of the crash has changed. I'm not sure when this began happening, but if I had to speculate it happened with the upgrade to 6.11.3. Previously, my system interface would hang - no UI, nothing. I could still SSH into the box and run diagnostics and navigate, but I couldn't do anything else. I understand from others this was their functionality as well. Performing a "docker stop $(docker ps -q)" would kill all the dockers and allow me to restart without a reboot. Now, the only thing that hangs on the system is my torrent docker (in my case, binhex-qbittorrentvpn). The UI continues to be accessible as well as SSH. This would seem to be a good sign, however "docker stop $(docker ps -q)" no longer stops all my dockers - it leaves binhex-qbittorrentvpn "running" (zombie). Nothing I've found has been able to fix this, short of a reboot. For instance, I can run a "/etc/rc.d/rc.docker stop", which won't succeed. a "/etc/rc.d/rc.docker force_stop" does work, but upon executing a "/etc/rc.d/rc.docker start" qbittorrent looks like it is running but running a "docker logs binhex-qbittorrentvpn" shows no new entries from the last. In short, while the UI now remains functional and the rest of the system can be accessed (apparently as normal), there is no fixing the qbittorrent docker without a reboot. It's unclear to me as to what rebooting does to correct the issue as I have nothing else to go on. I say all this to sadly say I know not everyone here is using qbittorrent while experiencing this issue, thus my findings are likely in some way unique to my config. There is some sliver of hope in that upon trying to start the docker engine back up, I receive the error message "Error response from daemon: failed to allocate secondary ip address (server:192.168.3.1): Address already in use". That's not a subnet that I've been using, so maybe there's some cross-over that I'm not seeing. I'm safe to disable/delete it, so I'll turn that knob and see if it affects anything. Sorry, not much of an update from my situation.

Since I'm 100% on crashes since I've increased the qBittorrent load, I took today's crash to dig around a bit more when trying to figure out how to cleanly shutdown things. As I mentioned before, "docker stop $(docker ps -q)" no longer shuts my docker engine down completely - the qBittorrent docker continues to zombie. Yesterday turning the docker engine off via the settings tab throws an error and a reboot to fix that error throws the array into parity check. Today, instead of killing the docker engine (which apparently does zero good for my situation) I simply tried to take the array offline, which resulted in a repetitive error message above (it's repeated 100+ times during the writing of this). cache I can understand - I do write to it when I categorize a torrent into a "Movie_LongTerm" state (stored on the array). However disk5 was news to me. Disk 5 is the only disk with a "games torrent" directory on it. I'm not sure if this is an indicator of specific functionality being suspect or simply that it failed randomly why trying to do games processing (raring, moving, etc). I can say that the game torrents tend to be the most accessed and largest files on the system (some are 300-400gigs each). So while I look into @JorgeB's proposed test today, I wondered if anyone might be able to share command line commands that would be more "intrusive" in taking my array offline and/or being able to kill the qbittorrent docker WITHOUT throwing my entire system into a state of parity recheck? As a BTW: I'm at 6.11.3 now, and this is occurs. Not that there was any help that a random version increment would have corrected it, but still...

I switched a heavier IO load back over onto my Unraid qBittorrent docker yesterday. Last night at 2am the issue occurred again. Same exact (to the row) error messages. The last several times I've had this occur, I've noted that the "docker stop $(docker ps -q)" would kill every docker EXCEPT qBittorrent, which would continue in a "running" state. I could force it closed by turning off the docker engine via the Unraid UI, but turning the docker engine back on in the same manner always presented me with an error message: The only way I've been able to find to correct this issue is with a reboot. Though admittedly I'm no command line docker expert. Thus, it looks like if I put my heart into it, I'm able to reproduce this issue with a fair amount of regularity. As far as my configuration of qBittorrent goes, its PRIMARY drives are both Unassigned Devices mounted: a 1TB NVME for the initial download and a 12TB spinner also mounted by Unassigned Devices. That 12TB drive is identical to the other 6 that I have mounted as part of Unraid's primary array, so my logic is that there shouldn't be any difference of hardware there causing this particular issue. Depending on the category of torrent, however, qBittorrent may also access files on the primary Unraid array. It isn't common, but it does have that ability. Just updating with this week's random Unraid problems on this topic...

I have a need for dockers on two different docker networks to communicate with one another. My situation is as follows: I run a "none" network for most media dockers that routes traffic through an "OpenVPN" container. I run an independent "qbittorrent-vpn" docker on my "bridge" network (that I'll eventually move across to my "docker-net" network when I get this situation sorted). There are apps (such as cross-seed and autobrr) that I need to have access to the qBittorrent-vpn docker. I'm in search of a configuration/setup/command that allows routing across network, if possible. I've attempted creating a third network and connecting the containers therein, but I receive an error message that I'm unable to sort: Any input as to either an easier way to make this happen or troubeshooting steps for the error message above? Thanks.

Also Ryzen. Moved most of my torrents from unraid to a seedbox (might be averaging 1.5mibs now), and the frequency for me has stayed about the same: Once every 5-8 days - longest I've ever gone is 10.5 days. My logs are the same as the logs I've posted 12 or so times before, so I won't bore with duplicate details. Now I'm just down to Plex pulling on the system, and I refused to off-load it. If this config won't function as a basic media server serving up 2-3 movie views per 24hrs, well... Again, the (temporary) fix for me every time is to stop the docker engine and restart. Works 100% of the time.

Next closest log entry prior to that was 36+hrs before

@JorgeB I don't have the diags, but do have the log. And also note: This "crash" must have happened earlier than I had noticed (according to the log). A trim action took place two hours later when things really hit the fan. Doubt any relevance, but still: