nft2

Unhelpfully I can say that I had the same issue early this year and I just bit the bullet and reinitialized the drive. I knew it would only take me an hour or two to get back to where I had it though. I personally found that error to be a bit unusual (What does it mean "wrong"? How did it disappear"? I never found out). Maybe you can mount the drive from the command line and get the files off it. If the file system is broken, maybe it can be repaired. I'm not very familiar with that but a quick Google tells me that may be unsound advice with btrfs. YMMV but worth investigating. If it mounts your problem might be solved. Cache drives aren't encrypted IIRC so at least you don't have to deal with LUKS. I probably wouldn't spend a ton of time on it though. In future, its worth having backups of the critical Docker configs on-array.

For the purposes of helping you I'm going to assume by "crash" you mean its hanging or becoming inaccessible. If you follow up with an answer try to explain the problem clearly (not intending to be rude but I'm about to explain quite a bit based on a guess of what you meant). I'm also assuming that you mean all the other Docker containers on your system are hanging, or the Docker page and/or entire Unraid GUI is slow. I had the problem as I described it earlier this year and the issue was that qBittorrent was hogging a ton of FUSE descriptors. This is a problem that emerged over time because a fresh server with no torrents doesn't have many files it's accessing, so even a poorly-configured setup like mine was fine for several years. The other part of the problem (the configuration issue) was that it was a mistake to use the FUSE abstraction for qBittorrent's AppData Config Path (Docker > qBittorrent/Edit > Scroll to the bottom and uncollapse "Show more Settings"). As far as I'm aware, that statement is true for any Docker container if you have a cache drive on which your Dockers reside. It's probably true if you don't as well. From memory, I think you can tell if it's using the FUSE abstraction layer if the path is something like /mnt/user/cache/appdata/binhex-qbittorrentvpn. You want to change it to the non-abstracted path, which in this case would be /mnt/cache/appdata/binhex-qbittorrentvpn. Note that if you do this and you had a badly configured setup like mine, you may need adjust your cache share to move the files from Array BACK to the Cache, which sounds strange but it allows the system to marshal all the randomly distributed Docker-related files back to where they need to be. The alternative is simply starting fresh with a new, correctly configured qBittorrent install and not worrying about it. This was a real head-scratcher to figure out when it happened to me, so I hope this helps you or someone else who encounters this post.

I was having an issue yesterday that I was able to solve, but couldn't find much help searching. Google does index this thread so I wanted to post for the benefit of others: I've been using this container for years with almost no issues, but yesterday a problem emerged where the container would hang/fail silently during startup after the log message "script finished to assign incoming port". At first I thought this might have been a problem with having too many torrents open because that had caused the container to get progressively slower in the past. I also suspected a DNS issue because of the way qBittorrent was behaving prior to me restarting it. It sounds like some of the other commenters are talking about a potential PIA issue occurring yesterday as well, which may have been part of the problem as I am also a PIA user. It turned out that I may have had my container misconfigured all this time. I had STRICT_PORT_FORWARD set to 'yes', but I don't think I've ever needed or used that functionality (again, it's been several years running this container with minimal issues and I may have forgotten). As I recall, the log messages have always complained that my chosen VPN region did not support port forwarding, but it always worked anyway so there was no need to fix something that wasn't broken. EDIT/UPDATE: It turned I did actually need port forwarding for one of the trackers I use, though this is somewhat irrelevant because it did (apparently) solved the hanging issue, though I don't want to be bothered restarting the container to be sure at the moment. I expect I can probably just tamper with the .ovpn file to open the port but that's a project for another day. I just wanted to update my message for completeness. Setting STRICT_PORT_FORWARD to 'no' solved the problem. As an added bonus, the container now starts much faster than it usually does. That may be due to clearing out a rather large log file that had accumulated and/or some other housekeeping step I took while trying to figure this out. What caused this problem to emerge now rather than any other time remains a mystery. It's possible the issue the other commenters are describing was the catalyst, although the log messages didn't indicate anything that led me in the direction of a PIA outage. I had used an interactive terminal to check DNS from within the container and it seemed to be working correctly. And just as a post-script: Thanks for such an easy to use torrent client for Unraid. When I first got set up years ago it would have been well beyond my capability to DIY anything like this from scratch. I appreciate you.