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.

After upgrading to 7.0.1 from 6.12.something, I noticed that the server has become unresponsive frequently. Server log shows multiple lines like I think the WebUI as well as SSH connection become sluggish as soon as a Docker container starts doing some data reading/writing, though I can't say for sure if that's the cause or only a symptom. I tried searching around a bit but didn't find anything conclusive about this problem. There are suggestions to install more memory or checking rootfs size, but I don't think they apply since neither of those are close to being full on my server. I have attached the diagnostics that I got during such a slow down. Thank you in advance for any advice. tower-diagnostics-20250306-2259.zip

It was that rclone script indeed. I fixed the remote config and the script is actually backing up my file now, instead of trying to write to a nonexistent exit directory on the root file system. As for why the rclone config ended up the way it did, I probably tried to exit out of the rclone config by typing in "exit" at the remote name step. 😅 I'm just glad rclone didn't overwrite anything important apparently.

I do have user scripts, and this one rclone script runs at 3AM. I recently poked around in the rclone config a bit, and might have bungled something up. Checking the log file created by that script revealed this: 2024/11/29 16:13:33 DEBUG : rclone: Version "v1.68.2" starting with parameters ["rcloneorig" "--config" "/boot/config/plugins/rclone/.rclone.conf" "sync" "-vv" "--log-file" "/mnt/user/Logs/rclone.txt" "/mnt/user/Chonky/Backups" "encrypted_b2:"] 2024/11/29 16:13:33 DEBUG : Creating backend with remote "/mnt/user/Chonky/Backups" 2024/11/29 16:13:33 DEBUG : Using config file from "/boot/config/plugins/rclone/.rclone.conf" 2024/11/29 16:13:33 DEBUG : Creating backend with remote "encrypted_b2:" 2024/11/29 16:13:33 DEBUG : Creating backend with remote "exit" 2024/11/29 16:13:33 DEBUG : fs cache: renaming cache item "exit" to be canonical "/root/exit" 2024/11/29 16:13:33 DEBUG : <filename>: Need to transfer - File not found at Destination 2024/11/29 16:13:33 DEBUG : <filename>: Need to transfer - File not found at Destination 2024/11/29 16:13:33 DEBUG : <filename>: Need to transfer - File not found at Destination I don't think the remote "exit" is supposed to be there. Will continue to investigate.

Thank you bmartino1 for your detailed replies. I will review settings and setup further logging before 3AM. The remounting tmpfs tip seems promising too, hopefully next time I will be able to get a proper diag before reboot.

Recently my server (Unraid 6.12.11) has been behaving strangely. - Syslog starts getting these error from around 3AM everyday (JST, so UTC+9). Natually I haven't been awake to catch it live, so all I can get are from logs later in the morning: https://pastebin.com/E60PBcUa - I could SSH into the server, the Docker containers seem to be running, but du -h / shows that the flash drive is full. The culprits seems to be some randomly named directories under /usr/local/emhttp/exit/. - I tried to run diagnostics through SSH, but as the flash drive was full, the generated diag zip was empty. - Hardware parts seem to be fine, the server run throughout the day without any error. - After a reboot everything seems fine again. I have attached a diag after reboot. Please let me know if there's anything else I can do provide to help solve this weird problem. Thank you. tower-diagnostics-20241129-0937.zip

Turned out on this motherboard, the lower PCIe 4x slot is disabled with both m.2 drives installed. I'm not sure why it didn't work the first time I pligged the HBA card into the top slot, but it does now. Please close the topic as I can't seem to delete it myself.

Hi everyone. I just upgraded the motherboard/CPU/RAM on my Unraid box while keeping everything else. Currently I have the following installed: CPU: AMD Ryzen 5 3600 Motherboard: ASRock B450 Steel Legend RAM: Corsair Vengeance DDR4 8GB 3000 As well as an LSI 9240-8i SAS HBA card that was working before. The new build boots up and I can get into Unraid WebGUI, but all the hard drives that I have plugged into the HBA card don't show up. The card was working before so I'm not sure what could be the problem. I have tried the following: Switching from UEFI boot mode to BIOS (by renaming the EFI folder on the USB stick to EFI-) Taping the B5/6 pins on the HBA card Switching between the 1st and 4th PCI-e slots At the moment I don't have a spare graphic card so I can't access the BIOS or do anything that would require a display output at all. I have attached the diags below. Any advice would be appreciated! tower-diagnostics-20241026-1500.zip

Hi JorgeB, thank you for your suggestion, and sorry about not replying until now. After a few hours that day, I decided to abandon the cache altogether and rebuild the Docker containers from the latest backup. Thanksfully that went well and the unraid box has been running nicely since then. Right now I have all shares (including appdata and system) running straight from the array, to avoid SSD shenanigans. 1 of the SSDs was indeed dead, so I just use the remaining one as a pure write cache now.

Today I woke up to find 1 SSD of the 2 assigned to the cache missing. I disabled Docker, did a full shutdown then boot it up again. The array failed to start by itself, as 1 of the 2 SSD was still missing. I tried to start the array anyway and it did, with the cache still unavailable. Is it possible to recover data on the cache? There is only Docker appdata there, and I have weekly backups so it's not too bad if it's lost, but still would be nice to have the thing running until new SSDs arrive. Diags attached. tower-diagnostics-20230901-0935.zip

I would like to forth that. Also attaching my diagnostics. tower-diagnostics-20230415-2203.zip