Manchineel

This is still a problem btw. Downloads are at sub 200 KB/s speeds, while I'm on a symmetric gigabit fiber line.

Question as per title. I've been using Unraid for years and I'm familiar with the XOR-based (parity 1) and the Reed-Solomon Code (parity 2) approaches to parity. While I therefore do know what Unraid ends up storing on the parity drive(s), I've been asking myself: how does Unraid update parity in real-time—what is the magic sauce? It appears that parity is always updated when writing to Unraid array disks, whether I'm accessing them through a user share (`/mnt/user/`) or by accessing the XFS-mounted filesystem directly (/mnt/disk1, /mnt/disk2 etc.). Additionally, how can Unraid instantly pick up all new FS reads/writes and suddenly start redirecting them to the emulated disk hosted by Unraid in the event of a drive failure, without breaking currently running apps, existing file handles etc.? Is it a modification of the XFS/BTRFS/ZFS/ReFS drivers within the Linux kernel employed by Unraid? (If so, supposedly LimeTech will have published the source somewhere to comply with GPL-2)? Is it something in the userspace (and if so, how can it capture such low-level block device events)? Or is there some Linux utility to create a virtual partition/disk (at the block level) and insert additional software interrupts on access events while relaying the operations to an upstream block device?

I'm on 6.11.5 actually

Glad I'm not alone. Also having the exact same experience. @Sarge what were the steps you took to fix this? ark-diagnostics-20230602-2121.zip

This is still an issue. Anyone found a fix yet?

To make changes persistent: Disable apcupsd by resetting settings to Default in UPS settings Open the terminal and copy your current logrotate script for apcupsd to your boot flash drive: mkdir -p /boot/config/custom/ && cp /etc/logrotate.d/apcupsd /boot/config/custom/apcupsd Open the script you copied on your flash drive using an editor (e.g. nano /boot/config/custom/apcupsd) and remove the following lines: postrotate /etc/rc.d/rc.apcupsd restart 1>/dev/null || true endscript Mine looks like this after making the changes: /var/log/apcupsd.events { rotate 4 weekly notifempty missingok } Now make sure your /boot/config/go script will overwrite the logrotate.d config with the updated file on boot: echo "cp /boot/config/custom/apcupsd /etc/logrotate.d/apcupsd" >> /boot/config/go To test that it works and apply the changes now, copy the file and run the logrotate job: cp /boot/config/custom/apcupsd /etc/logrotate.d/apcupsd && /etc/cron.daily/logrotate

Eventually found a proper solution! Disable apcupsd by resetting settings to Default (see above) Open the terminal and copy your current logrotate script for apcupsd to your boot flash drive: mkdir -p /boot/config/custom/ && cp /etc/logrotate.d/apcupsd /boot/config/custom/apcupsd Open the script you copied on your flash drive using an editor (e.g. nano /boot/config/custom/apcupsd) and remove the following lines: postrotate /etc/rc.d/rc.apcupsd restart 1>/dev/null || true endscript Mine looks like this after making the changes: /var/log/apcupsd.events { rotate 4 weekly notifempty missingok } Now make sure your /boot/config/go script will overwrite the logrotate.d config with the updated file on boot: echo "cp /boot/config/custom/apcupsd /etc/logrotate.d/apcupsd" >> /boot/config/go To test that it works and apply the changes now, copy the file and run the logrotate job: cp /boot/config/custom/apcupsd /etc/logrotate.d/apcupsd && /etc/cron.daily/logrotate

@Sascha_B's post clearly explains the odd leftover Docker interface, but not why Unraid chose to split the address space for shim interface routing rules in half. My home network is a /16 and for some reason, just like in @tknx's case, I have two /17 rules rather than a single /16. This being the default behavior is also confirmed by this guide I was following, which "fixes" the fact that Unraid often fails to create the shim interfaces altogether with a script to automatically create the routes on array start—the poster also splits the /24 route into two /25s in his script. I haven't tested what will happen if you use a single /16 rule, although I can't see why it shouldn't work all the same—this is all but clearly the doing of some spaghetti code on Unraid's part. Besides, the only difference should be that this way a container with its IP at exactly half the address space (network address of the 2nd subnet, or the bogus "broadcast" IP of the 1st subnet preceding it) will not route properly. I doubt the "Host access to custom networks" option does anything more than create this interface and the two weird rules, so it should probably be safe to set the option to Disabled and replace it with the solution linked above but using a single forwarding rule. I'll do a few tests and report on my findings, probably create a bug report.

I wanted to add for future reference: do NOT, and I repeat, DO NOT, ever mount drives belonging to the array automatically/in read-write mode outside Unraid (or from the Unassigned Devices plugin) if given the option. It will cause your parity to silently become invalid. If by accident that should happen, however, do not add back your parity, do not resilver disks, simply wipe parity and rebuild it from scratch (or using the "fix errors" mode on parity rebuild — errors are normal then: the parity has not been informed of the changes made by other OSs or a raw mount), and make sure turbo/reconstruct write is disabled while you do this. It will silently corrupt your data otherwise.

Just installed it, and unfortunately it doesn't work. When I try to connect to the WebUI, I keep getting [WARNING] unable to add HTTP_UPGRADE_INSECURE_REQUESTS=1 to uwsgi packet, consider increasing buffer size spammed in the Docker logs, and the page doesn't load ("The connection to the server was reset while the page was loading."). Any solution?

I got an Eaton Ellipse Eco 1200 (1200VA/750W) to use with Unraid and it's detected out of the box when connected via USB. I'm using the built-in Unraid UPS menu in the WebUI, with apcupsd. So far I have no complaints; Unraid says the battery should give me about 50 minutes of power (which is great) and unplugging the UPS from the outlet immediately triggers a Telegram and Email notification.