Kagoromo

It is actually my LAN network I chose that precisely to avoid ambiguity with the typical LAN IP ranges like 192.168.x.x. Thank you for pointing out the relevant FAQ, I will give that a try. Edit: Yeah that was it, the PIA server I was using wasn't available anymore it seems. I edited the ovpn file to point to a different server and now it works again.

Hi, I have been getting startup problem with the latest image since 2 days ago as well. I can't reach the Web UI unless I disable the VPN. I have attached the docker run command and supervisord.log below. I hope they will help with diagnosing. docker run -d --name='qbittorrent' --net='bridge' --cpuset-cpus='1,2,3' --pids-limit 2048 --privileged=true -e TZ="Asia/Tokyo" -e HOST_OS="Unraid" -e HOST_HOSTNAME="Tower" -e HOST_CONTAINERNAME="qbittorrent" -e 'VPN_ENABLED'='yes' -e 'VPN_USER'='<redacted>' -e 'VPN_PASS'='<redacted>' -e 'VPN_PROV'='pia' -e 'VPN_CLIENT'='openvpn' -e 'STRICT_PORT_FORWARD'='yes' -e 'ENABLE_PRIVOXY'='no' -e 'WEBUI_PORT'='31000' -e 'LAN_NETWORK'='52.46.69.0/24' -e 'VPN_INPUT_PORTS'='' -e 'VPN_OUTPUT_PORTS'='' -e 'DEBUG'='true' -e 'ENABLE_SOCKS'='no' -e 'SOCKS_USER'='admin' -e 'SOCKS_PASS'='socks' -e 'VPN_OPTIONS'='' -e 'NAME_SERVERS'='84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1' -e 'UMASK'='000' -e 'PUID'='99' -e 'PGID'='100' -e 'ENABLE_STARTUP_SCRIPTS'='no' -e 'USERSPACE_WIREGUARD'='no' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:31000]/' -l net.unraid.docker.icon='https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/qbittorrent-icon.png' -p '31001:6881/tcp' -p '31001:6881/udp' -p '31002:8118/tcp' -p '31000:31000/tcp' -p '8080:8080/tcp' -p '9118:9118/tcp' -p '58946:58946/tcp' -p '58946:58946/udp' -v '/mnt/user/Flowy/':'/media':'rw' -v '/mnt/user/appdata/qbittorrent':'/config':'rw' -v '/mnt/user/Flowy/':'/data':'rw' -v '/mnt/user/Torrent/':'/incomplete':'rw' -v '/mnt/user/Torrent/':'/cache':'rw' -v 'binhex-shared':'/shared':'rw' --sysctl="net.ipv4.conf.all.src_valid_mark=1" -m 4G --log-driver syslog --log-opt syslog-address=udp://127.0.0.1:541 --health-interval=60m 'binhex/arch-qbittorrentvpn:latest' WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap. fbbc01d550b5c8f1b6d9af0a8f814bc82e547fb7ac957bda12323f40e3778bd8 The command finished successfully! supervisord.log

Thank you for the links. This copying files between disks seems to be more perilous than I previously thought. What do you think about the Unbalance plugin? I have used it a few times before and I was not under the impression that it was unsafe.

That's fair! I understand that mine is a niche requirement. I will try making a userscript to do what I want on a schedule.

Yeah, that certainly could work. Ideally I would like to automate the setup a bit more though. Basically I want all shares to write to all disks, but only share "Linux" will try to fill up disk 1 to full before moving to other disks, and other shares will try to fill disk 2-5 before trying disk 1.

Hi, this time it's just an optimization idea and not an actual down time scenario, yay! This is what I want to do: I have a typical array and a pool cache setup. I like the hard drives to spin down as much as possible when not being used, so the spin down delay is very low (15 minutes). I also want to speed up random access for media stored on the array, and spinned down disks add a lot of delay. The obvious idea is to make those files live on the pool cache, but the pool cache is not big enough to hold all of them. However they do fit on a single array disk. So why not keep those files on a share that prefer a certain disk that will be kept always spinning, while making all other shares avoid filling up that disk unless necessary? That's where I'm at currently. I have looked around but don't see much interest in this kinda setup. There was this discussion https://forums.unraid.net/topic/37071-possible-to-prioritize-disk-usage-order-for-share/ but they didn't arrive at an answer. I have tried it myself but Unraid 7 doesn't seem to allow manual prioritizing of fill-up. I would appreciate any idea for how to accomplish this. Thanks in advance.

I swapped in another pair of old but good DDR4 sticks, and the server booted up fine. Scrubbed the pools, deleted the corrupted files (1 was an Appdata backup tar file, kinda ironic). Parity check is still running but so far so good. Containers are back up for now. Thanks for the help as always, @JorgeB !

Hi 👋, I'm checking back in to share a gotcha that I recently met. I'm still using the ramdisk method with user scripts running at the start/stop of the array, as well as every 15 minutes. The only difference is that I use the /dev/shm/ directory instead of mounting a custom ramfs. The problem had to do with the Appdata Backup plugin. As you can see in the image, volumes mounted using the ramdisk don't count as internal and thus don't get backed up by default. (note the icon to the left of the path) For this particular container, I have to select "Save external volumes? Yes" and define custom exclusions, because I only need to backup the appdata volume of the container and not the media files. Since I wasn't aware of this feature before, I have been spending a long time not actually having backups of a few of my containers. Today it finally came to a head and a database file in one of those containers was corrupted due to bad RAM, and I didn't have a backup to restore it. 🫠 I hope my bad luck will help other people.

I got bad RAM indeed, memtest86+ did the trick. Replacements are on the way. What about the SSDs though, is it too early to say if they are also bad?

Thank you @JorgeB, will do and report back later.

I have 2 pools, cache with only 1 1TB SSD as the write cache and nvme with 2 256GB SSD to run containers from. I think all of them might be giving up the ghost and I would like some confirmation before I find replacements. Please check the attached diagnostics. Thank you in advance for any advice. tower-diagnostics-20251017-0944.zip

I have downgraded to 6.12.11 and the server is running smoothly again.

Yeah you are probably right. I was too quick to come to that conclusion as Web UI was still locking up. I tried a few other things but finally gave up and setup CPU pinning so the Docker containers only use cores 1-3 and core 0 only for Unraid. It seems to work for now. I wonder why that's necessary now on 7.0.1 though, 6.12.11 was running without a hitch.

This morning I checked the server log and found that the php errors were still being produced, however, there were also these lines: As such, I went and removed that Memory Tester plugin, as well as a few other that I don't use anymore. After checking back in the afternoon, the system log seems to be clear of errors and the Web UI seems snappy as it should be, so I think that plugin might have been it.

Thank you JorgeB, I will first try these and see how it goes. If things still don't improve I will then try the CPU pinning, though that might be a bit awkward since the CPU I'm using only has 4 cores and no Hyperthreading (i3-8100), so there is not much room to play with.