Leseratte10

I mean, they could just offer the solution if people want it. Just make a toggle somewhere when you buy the license - do you want a license that's bound to a USB drive or do you want a license that's bound to the internet and requires connecting to a server every week or so to verify it's already valid. Best of both worlds and everyone can choose what they like best. One easy way to solve that would be to add some mapping in UnRAID. Like "ZFS is introduced on 2024-xx-xx, some-other-new-feature is introduced on 2025-xx-xx" and that for each new actual feature that's released. Then they can let everyone update to the newest UnRAID to get security updates and bugfixes (even if the license is expired), but UnRAID can check the date the license file was issued at, and only allow people to use ZFS or "some-other-new-feature" if the license file was valid at the point in time where said feature was added. This means that they wouldn't put OS updates and bugfixes behind a subscription, just actual new *features*. And they don't have any extra work maintaining two branches, all they need is a simple feature toggle in the latest UnRAID that blocks the new feature if the license is too old. But I guess that depends on what LimeTech *wants*. Do they actually want to put all updates behind a subscription wall (including security fixes and bugfixes) and are only selling it with the "new features cost money to develop" take - or do they actually *want* to only charge for actual new features and just figured limiting access to updates is the easiest way to do that? I'd be pissed if right after my subscription ended a new point release was released that fixed bugs that I reported earlier, or fixes important CVEs that have just been published, and I couldn't install that ...

Do you have any plans to decouple OS security updates (which every user should get even if their license is expired) from UnRAID feature updates, then, if people with an expired license don't even get minor updates? Otherwise quite a few UnRAID boxes are going to become outdated security risks and are going to get hacked eventually ...

@limetechIf the support / development work for two or more seperate branches is too high, have you thought about allowing everyone to update but lock down new features? So, like, even with the limited license you could update UnRAID forever, but once you add a new large feature to the UnRAID system like ZFS or whatever the last larger update was, you could add code to UnRAID that's like "Only allow people to use this feature if they're on Pro, Lifetime, or their key was bought after the feature was introduced". That way you'd only have one branch of UnRAID to update, everyone (even those with subscription keys) can update to the newest version and receive security updates and fixes, but new features would require people to either have a Pro or Lifetime license, or a currently valid subscription license. Looking through the last couple of updates, quite a few changes are security-only, or bugfixes for past issues. If I had a temporary license for a year, I'd be pissed if I updated to a new version that introduces some new bug, but then my license expires and I won't be able to update to the next release that hopefully fixes it. The number of big new features hasn't really been that high recently, so the additional work of locking new features behind a "your key must be up-to-date" shouldn't be that much.

In case anyone else runs into this issue, too, I've opened a bug report, and created a small Unraid plugin that works around this issue: https://github.com/Leseratte10/unraid-plugin-bind-all This should make all services listen on [::] (IPv6) and 0.0.0.0 (IPv4) just like in 6.11.5. Note that this plugin isn't really tested that much and it's my first plugin so make sure you can access the server if this breaks networking somehow. You can install it by going to Plugins -> Install Plugin and entering this URL: https://github.com/Leseratte10/unraid-plugin-bind-all/blob/master/leseratte.patch.listen-on-all-ips.plg

Can confirm, something is broken in 6.12.x. In 6.11.5, the nginx webserver was simply configured to listen on "0.0.0.0" for IPv4 and "[::]" for IPv6 which made it listen on all IPs: listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; Since the 6.12.0 update, it's listening on hardcoded addresses: listen 10.0.2.140:443 ssl http2 default_server; # eth0 listen [2001:db8:1234:5678:1234:56ff:fe78:90ab]:443 ssl http2 default_server; # eth0 Same for the SSH server: #Port 22 AddressFamily any ListenAddress 10.0.2.140 # eth0 ListenAddress 2001:db8:1234:5678:1234:56ff:fe78:90ab # eth0 This is terrible. My network uses global IPv6 addresses for outgoing internet connections and ULAs for internal access. This change, when I updated from 6.11.5 to 6.12.6, made it so I was unable to access my Unraid server since it's no longer listening on the correct addresses. Also, hardcoding the address itself is terrible for dynamic IPv6 prefixes since it requires some daemon to A) notice the prefix change, B) rewrite the nginx/SSH/SMB/whatever config, then C) reload the server. Can this be fixed somehow? I checked the new "Interface extra" section in the Network Settings that was mentioned in the release notes, but that's useless. It looks like Unraid just checks for the current IPv4 and IPv6 address on the interface that's entered there, and puts that into the Nginx config. So, that will probably break when the IPv6 prefix changes, and it *definitely* breaks for ULAs and when there's more than one IPv6 address on an interface. This looks like yet another case where new network "features" again weren't properly tested with IPv6 prior to release. Can the priority for this bug be increased? In my opinion, no longer being able to access the WebGUI AND the SSH server over IPv6 is more than an "annoyance that doesn't affect functionality". Thank god I did that OS update in person instead of over a remote connection, otherwise I would have been locked out. Can you just give us a toggle to revert back to the old behaviour of just listening on "::"? EDIT: Looks like I can enter an ULA into the "Include listening interfaces" and thankfully that'll get added to the SSHD and Nginx config files (so I can access the server remotely again), but still, that'll break when the ULA or GUA prefix changes as then I'd need to manually alter the config again. How does something like this end up in a release?

I'm trying to use UnRAID's built-in syslog server to receive logs from a bunch of other machines in my network. The general logging itself is working fine, but I really don't like that UnRAID is using the client's IP address for the file name. Some clients connect over IPv4, some connect over IPv6. Some even switch between IPv4 and IPv6 (maybe one of them is down sometimes) and the logs end up in different files. Some are clients with a dynamic IPv6 (privacy extensions). I tried to have my remote backup UnRAID server send its logs to the "main" UnRAID server, too - but given that that server is behind a dynamic public IP, UnRAID will create new syslog log files over and over again every single time the IP changes. That makes the logs pretty useless since you can't really find stuff. Given that the syslog protocol is a standard format and each log entry starts with the date/time and then the hostname of the sending machine, why does UnRAID use an IP which can change all the time for the file name? Can a setting be added to UnRAID's syslog server so the file name for the received syslog messages contains the server name sent inside the syslog message (which will be constant) instead of just using the source IP address (which changes all the time)? EDIT: Looks like the relevant config is in /etc/rsyslog.conf: # ######### Receiving Messages from Remote Hosts ########## # TCP Syslog Server: # provides TCP syslog reception and GSS-API (if compiled to support it) $ModLoad imtcp # load module #$InputTCPServerRun 514 # start up TCP listener at port 514 # UDP Syslog Server: $ModLoad imudp # provides UDP syslog reception #$UDPServerRun 514 # start a UDP syslog server at standard port 514 $template remote,"/mnt/user/syslog/syslog-%FROMHOST-IP%.log" I could probably just edit this and modify the path, but I'm not sure when/if that'll be overwritten again by UnRAID. Basically, I'd just like to have an option in the UnRAID GUI to replace that stupid "%FROMHOST-IP%" with "%HOSTNAME%". The corresponding code in the webgui repo that would need to be changed is here. EDIT 2: Also, while we're at it, the HTML input field for the remote syslog server hostname is limited to 23 chars which is pretty short for a server name. When I edit the HTML and remove that restriction I can add a longer server name and it also works. Can that limit be removed / increased? EDIT 3: PR: https://github.com/unraid/webgui/pull/1563

Great Plugin, I started to use this to automatically create backups of my Docker container data (lives on the cache drive) to the main array. When I started using it I added the "noParity" flag because I didn't want to have backups or other intensive tasks running on the array during a parity check or data rebuild - and then a month later wondered why it didn't run the backup for two days in a row ... Would it be possible to add another flag that auto-pauses a Parity Check or Data Rebuild if it's currently running? So, a flag like "pauseParity" that checks if a Parity operation is currently running before it starts the userscript, and if so, pause the operation, run the userscript, then start it again? Or would that cause any issues like when running multiple scripts in parallel?

I'm also looking for a fix for this issue. Spent hours debugging my own code until I figured out the UnRAID host (6.11.5) is not reachable over IPv6 from within a container ... Any way to change this stupid behaviour? I tried manually setting routes but they seem to be ignored ... EDIT: Solved the issue by throwing a second NIC into the system. 1st NIC is for UnRAID and for all VMs, 2nd NIC is just for Docker containers. That way traffic is forced to go out NIC2, through the switch and into NIC1 which makes that work. Still hoping there can be a proper solution in the future - kind of a waste of a NIC (and power)...

I'm running an UnRAID host with 6.11.5, and a bunch of VMs (network source br0, network model virtio-net) all running Debian 11. All VMs have "net.ipv6.conf.*.accept_ra = 2" set. One of the VMs is running radvd, announcing a route to the network: interface enp1s0 { AdvSendAdvert on; AdvDefaultLifetime 0; AdvDefaultPreference low; route 2001:db8:1234::/48 { }; }; Other devices on the network, Linux and Windows, are picking up this route just fine. "ip -6 r" on Linux, or "route -6 print" on Windows will display the route and use it. The UnRAID host itself and the other VM running on UnRAID, however, don't. Running a tcpdump or something like radvdump confirms that the route advertisements do reach the UnRAID host and the other VMs: # # radvd configuration generated by radvdump 2.18 # based on Router Advertisement from fe80::xxxx:xxff:fexx:xxxx # received by interface enp1s0 # interface enp1s0 { AdvSendAdvert on; # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump AdvManagedFlag off; AdvOtherConfigFlag off; AdvReachableTime 0; AdvRetransTimer 0; AdvCurHopLimit 64; AdvDefaultLifetime 0; AdvHomeAgentFlag off; AdvDefaultPreference low; AdvSourceLLAddress on; route 2001:db8:1234::/48 { AdvRoutePreference medium; AdvRouteLifetime 0; }; # End of route definition }; # End of interface definition However, the advertised route seems to not be added to the routing table. Is there some kind of setting inside UnRAID that could be blocking these? Both the UnRAID host and all the VMs correctly receive and use routes advertised by another physical machine on the same network, just RAs from the same physical machine seem to be ignored. Or could this be a configuration issue in the Linux VMs in that Linux somehow still figures out that the RA actually comes from the same physical device? The link-local address the RA is from (fe80::xxxx:xxff:fexx:xxxx) is the link-local address of the VM running radvd. I have attached the configuration from the radvd VM extracted from the Diagnostics. vmconfig.txt

The data rebuild is now finished, all drives are green / healthy again and all the data is still there. The slow rebuild was (most likely) caused by the "Folder Caching" plugin (which has a setting to not run while the mover is running but apparently no setting to not run during a Parity rebuild ...) so that mystery is solved, too. Thanks!

Okay, since my last post I've ordered a ton of additional fans for the machine, and a new 18TB drive. I've successfully precleared that drive in another unRAID machine and then replaced the broken drive. Added tons of additional fans to the machine and the data rebuild from parity is currently running. Drives are all running at 34°C now. Thanks for all the advice I've received so far. I have two additional questions regarding that, though: A) During the first ~2 hours of the rebuild, it was running very very slow. Like, 20-30 MB/s a second and it said it would take like a week to rebuild the drive. After 2-3 hours it shot up to more realistic speeds of 200 MB/s. Is this "normal" / is there anything else happening at the beginning of a rebuild that causes these slow speeds? I have the machine disconnected from the network and all VMs / Dockers stopped so there's nothing else using the disks. B) I've noticed that during the rebuild, all the other drives are hit with tons and tons of reads (duh, that's the point of parity, using the Parity bits and all other data bits to recreate one missing drive). I'm wondering, though, since I have dual parity, why would it not leave one disk spun-down? Since with two parity drives it would theoretically be able to recreate two broken drives at the same time, why not leave one of the disks alone, reducing the risk of an additional drive breaking due to the load of the rebuild? Why not leave Parity 2 down / not access it at all and just rebuild from Parity 1? Or even better, leave the data disk that ist most full (= has the most content at risk) spun down and use both Parity disks instead?

I have notifications enabled, and no, that disk hasn't been showing SMART warnings before. I got the notification about SMART errors just today. Last time I actively checked the dashboard was a couple days ago and everything was fine. And the notifications are definitely working, as I always see the ones related to Docker image updates. Only strange thing was a temperature warning for that disk today at 2:03am (49°C), then "returned to normal temp" at 3:23am, then "Array has 1 disk with read errors (49)" at 2:49pm, and then the panic alert "Disk 1 in error state (disk dsbl)" at 2:51pm. Other than that, no warnings. I should probably crank up the fan speeds a bit during the summer. Seagate says the drive can operate in up to 60°C and it did never reach that, so I assumed it was fine. Though, that question was more regarding the drive change process itself. I will post again once I have the new drive here and replaced the drive. Thanks for all the helpful answers so far.

So is there anything special I need to watch out for? Right now the server is running but the array is stopped. The broken disk has a red "X" and the others have their green bubble in the "Main" menu. Once I have the new drive I just un-assign the broken drive, shut down the server, replace the drive, go into the "Main" menu and assign the new drive to the slot that had the failed drive in it, then start the array, and UnRAID will automatically re-build the contents onto the new drive, as described at https://wiki.unraid.net/Replacing_a_Data_Drive ? Or is there a difference in procedure with replacing a working data drive vs replacing a failed data drive?

Here's the new diagnostics. Looks like a dead disk. 415 reallocated sectors (used to be 0), 2 reported uncorrected (used to be 0), and 3898 pending sector and offline uncorrectable. Zero CRC errors so unlikely to be a bad cable - right? Time to replace the disk, I suppose ... tower-diagnostics-20220805-1754.zip

While a (non-correcting) Parity check was running, I received a notification from my UnRAID server with the message "Disk 1 in error state (disk dsbl)", and on the "Main" page there's a red "X" where the green dot used to be next to the drive name. The data's all still there thanks to the parity drives - but how do I figure out what happened? The given disk is apparently disconnected from the OS, as /dev/sdd (which used to be that disk) no longer exists and I also can't view SMART data through the web interface. The OS log started with these: [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] mpt2sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000) [Fri Aug 5 14:49:19 2022] sd 5:0:0:0: [sdd] tag#1005 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=4s [Fri Aug 5 14:49:19 2022] sd 5:0:0:0: [sdd] tag#1005 Sense Key : 0x3 [current] [Fri Aug 5 14:49:19 2022] sd 5:0:0:0: [sdd] tag#1005 ASC=0x11 ASCQ=0x0 [Fri Aug 5 14:49:19 2022] sd 5:0:0:0: [sdd] tag#1005 CDB: opcode=0x88 88 00 00 00 00 00 0b 24 22 f0 00 00 04 00 00 00 [Fri Aug 5 14:49:19 2022] blk_update_request: critical medium error, dev sdd, sector 186918248 op 0x0:(READ) flags 0x0 phys_seg 49 prio class 0 [Fri Aug 5 14:49:19 2022] md: disk1 read error, sector=186918184 [Fri Aug 5 14:49:19 2022] md: disk1 read error, sector=186918192 [Fri Aug 5 14:49:19 2022] md: disk1 read error, sector=186918200 and then a bunch of these: [Fri Aug 5 14:50:57 2022] sd 5:0:0:0: attempting task abort!scmd(0x0000000057bd43b8), outstanding for 94137 ms & timeout 30000 ms [Fri Aug 5 14:50:57 2022] sd 5:0:0:0: [sdd] tag#1085 CDB: opcode=0x88 88 00 00 00 00 00 0b 24 6d c0 00 00 01 30 00 00 [Fri Aug 5 14:50:57 2022] scsi target5:0:0: handle(0x000a), sas_address(0x4433221102000000), phy(2) [Fri Aug 5 14:50:57 2022] scsi target5:0:0: enclosure logical id(0x500605b00c2a3ad0), slot(1) [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: task abort: SUCCESS scmd(0x0000000057bd43b8) [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: attempting task abort!scmd(0x0000000021903280), outstanding for 34003 ms & timeout 30000 ms [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: [sdd] tag#1084 CDB: opcode=0x88 88 00 00 00 00 00 0b 24 93 38 00 00 03 88 00 00 [Fri Aug 5 14:51:01 2022] scsi target5:0:0: handle(0x000a), sas_address(0x4433221102000000), phy(2) [Fri Aug 5 14:51:01 2022] scsi target5:0:0: enclosure logical id(0x500605b00c2a3ad0), slot(1) [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: No reference found at driver, assuming scmd(0x0000000021903280) might have completed [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: task abort: SUCCESS scmd(0x0000000021903280) [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: attempting task abort!scmd(0x0000000043132d6d), outstanding for 34046 ms & timeout 30000 ms [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: [sdd] tag#1082 CDB: opcode=0x88 88 00 00 00 00 00 0b 24 90 a8 00 00 02 90 00 00 [Fri Aug 5 14:51:01 2022] scsi target5:0:0: handle(0x000a), sas_address(0x4433221102000000), phy(2) [Fri Aug 5 14:51:01 2022] scsi target5:0:0: enclosure logical id(0x500605b00c2a3ad0), slot(1) [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: No reference found at driver, assuming scmd(0x0000000043132d6d) might have completed [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: task abort: SUCCESS scmd(0x0000000043132d6d) [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: attempting task abort!scmd(0x0000000098a39814), outstanding for 34106 ms & timeout 30000 ms [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: [sdd] tag#1081 CDB: opcode=0x88 88 00 00 00 00 00 0b 24 90 50 00 00 00 58 00 00 [Fri Aug 5 14:51:01 2022] scsi target5:0:0: handle(0x000a), sas_address(0x4433221102000000), phy(2) [Fri Aug 5 14:51:01 2022] scsi target5:0:0: enclosure logical id(0x500605b00c2a3ad0), slot(1) [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: No reference found at driver, assuming scmd(0x0000000098a39814) might have completed [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: task abort: SUCCESS scmd(0x0000000098a39814) [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: attempting task abort!scmd(0x0000000011352615), outstanding for 39686 ms & timeout 30000 ms [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: [sdd] tag#1079 CDB: opcode=0x88 88 00 00 00 00 00 0b 24 85 e8 00 00 00 d8 00 00 [Fri Aug 5 14:51:01 2022] scsi target5:0:0: handle(0x000a), sas_address(0x4433221102000000), phy(2) [Fri Aug 5 14:51:01 2022] scsi target5:0:0: enclosure logical id(0x500605b00c2a3ad0), slot(1) [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: No reference found at driver, assuming scmd(0x0000000011352615) might have completed [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: task abort: SUCCESS scmd(0x0000000011352615) [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: attempting task abort!scmd(0x0000000029d7771f), outstanding for 36822 ms & timeout 30000 ms [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: [sdd] tag#1077 CDB: opcode=0x88 88 00 00 00 00 00 0b 24 8d 28 00 00 03 28 00 00 [Fri Aug 5 14:51:01 2022] scsi target5:0:0: handle(0x000a), sas_address(0x4433221102000000), phy(2) [Fri Aug 5 14:51:01 2022] scsi target5:0:0: enclosure logical id(0x500605b00c2a3ad0), slot(1) [Fri Aug 5 14:51:01 2022] sd 5:0:0:0: No reference found at driver, assuming scmd(0x0000000029d7771f) might have completed The full log is in the diagnostics ZIP. What should be the next step to figure out if this is a dead hard drive or some other issue that goes away on its own, given that I can't view SMART data? Take the array offline and see what happens? Reboot and potentially lose helpful logs? Order a new HDD; shutdown server, and just replace the Disk? The "need help, read first" thread mentions to attach SMART reports, but that doesn't work given that I don't see the drive. Can I do any harm in rebooting the server to hopefully get the drive to show up to get SMART data? The overview on the Dashboard says "SMART healthy" for that drive, but if I click on "healthy" to get more information, that fails because the sdd drive is apparently offline. For now I shut down all VMs and Docker containers, but I'm not sure what I should do next. I have ordered a replacement drive if needed but due to the weekend it'll be a couple days until that arrives. Sorry for these stupid questions, this is my first (potentially) dead hard drive with UnRAID and I'm not exactly sure how to proceed. tower-diagnostics-20220805-1713.zip

I'm running Unraid 6.10.2, with my Docker containers in macvlan mode and with "Network Type" set to "Custom: br0". I'm then assigning a static IPv4 and a static IPv6 through the "Fixed IP address" option. However, the Docker container is only reachable (through IPv6) from my local network, not from "outside". IPv4 traffic is working fine. My router is definitely configured to accept that incoming IPv6 traffic to the container's IPv6. I suspect the issue is a wrong gateway. When I run "docker network inspect br0" on the UnRAID host, this is what I get: [ { "Name": "br0", "Id": "xxx", "Created": "2022-06-11T15:25:56.860307501+02:00", "Scope": "local", "Driver": "macvlan", "EnableIPv6": true, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "10.0.0.0/16", "Gateway": "10.0.1.1", "AuxiliaryAddresses": { "server": "10.0.1.5" } }, { "Subnet": "2001:db8:1234::/64", "Gateway": "2001:db8:1234::1", "AuxiliaryAddresses": { "server6": "2001:db8:1234:0:1122:33ff:fe44:5566" } } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "yyy": { "Name": "mycontainer", "EndpointID": "zzz", "MacAddress": "02:42:0a:00:18:07", "IPv4Address": "10.0.24.7/16", "IPv6Address": "2001:db8:1234::24:7/64" } }, "Options": { "parent": "br0" }, "Labels": {} } ] For the IPv4 gateway, it correctly lists "10.0.1.1" as the gateway (which is my router's private IPv4 address). However, for the IPv6 gateway, it lists 2001:db8:1234::1 as the gateway - an address that does not exist in my network at all. Thus, while my packets from the internet may reach the Docker container, I suspect the response never arrives because Docker tries to send the packets to that nonexistant address instead of the proper network gateway. In UnRAID under Settings -> Network Settings the "IPv6 default gateway" is correctly set to my router's link-local IPv6 address. Where does that weird 2001:db8:1234::1 address as IPv6 gateway in the Docker network come from? Under Settings -> Docker it also correctly lists "IPv6 custom network on interface br0: Subnet: 2001:db8:1234::/64, Gateway: fe80::1234:56ff:fe78:90ab". Unfortunately it looks like it's impossible to alter a Docker network after it's been created, so I can't just throw some code into the "go" file on the flash drive to automatically correct this after each boot. Also, even if that was possible, it sounds like a terrible hack. Where does UnRAID get that gateway from and how do I change it? Under "Network Settings" it correctly displays "IPv6 default fe80::1234:56ff:fe78:90ab via br0" as the route. Is there any custom settings as to how the br0 custom network is created that I could modify? What am I doing wrong? I grep'd through the whole USB drive for "2001:db8:1234::1" hoping to find any place where that'd be hardcoded but I didn't find any. Does UnRAID assume the gateway can always be reached through the 1st address from the IPv6 subnet? That'd be ... stupid. If necessary I can post a diagnostics ZIP, but I'd rather not have all my IPs and container names and stuff published (yeah, security by obscurity ...) so I'd need a bit of time to anonymize them all. If the ZIP is needed for this particular issue please just mention it. EDIT: I just found code in /etc/rc.d/rc.docker that explicitly implements this buggy behaviour: if [[ -n $IPV6 ]]; then SUBNET6=$(ip -6 route show dev $NETWORK $IPV6|awk '{print $1;exit}') SERVER6=${IPV6%%/*} DHCP6=${NETWORK/./_} DHCP6=DOCKER_DHCP6_${DHCP6^^} RANGE6=${!DHCP6} GATEWAY6=$(ip -6 route show dev $NETWORK default|awk '{print $3;exit}') # replace link local address for first address in subnet [[ ${GATEWAY6:0:4} == fe80 ]] && GATEWAY6=${SUBNET6%%/*}1 fi So it first determines the gateway as it should, using "ip -6", but then it decides to just ignore what it found and hardcodes the first address in the subnet instead? What's the point? That completely breaks stuff apparently. I'm going to try removing that code and see if that fixes my issue.

Yes, it is.

Thanks for your response. I can't find "force update all", do you mean "force scan all"? Just tried that and it doesn't help.

Just installed this plugin on my UnRAID machine, and noticed it doesn't take the purchase date and warranty duration from the drive settings. I've already configured purchase date and warranty duration under Main -> Disk X -> Identity -> "Date of purchase" and "warranty period", but the plugin doesn't seem to read (or write) these fields so one would need to update / fill in this data in two different locations which isn't ideal. Can the plugin be updated to read the data from the drive settings, if available?

That is true, but doing that (creating a smaller FS) makes sure that data is only written to the first 8TB of the disk (which would be parity-protected), doesn't it? Yes, it is typically possible to resize a filesystem. Why would that invalidate the parity? It's just normal writes to the disk ... I definitely agree with that. My suggestion was just about a solution when you've ran into the issue already, didn't plan ahead, and need more storage immediately. But looking at the other answers, it's probably not as simple as I imagined it to be.

The goal of the way I suggested would be *quickly* adding more storage to an UnRAID array when needed, without losing parity. The first method (which I described as "throw away parity" would mean adding the old parity drive as data drive, rebuilding a new parity onto the new 12TB drive. Which means my array will be unprotected while that happens. The second method ("parity swap") would require the array to be offline until the whole 8TB are copied, which will be quite a while. Yes, the method I suggested would result in you wasting space, but only until you manage to swap parity to a new 12TB disk at a later time, when a downtime is convenient. It was a suggestion for a method to add more storage to an UnRAID array without downtime and without losing parity. Yes, it would waste 4TB in this scenario, but I still feel it would be good to have this as an optional feature if needed - if I need a bunch of more storage immediately and don't want to wait for a parity swap.

I have not yet set up my UnRAID machine (I'm just in the process of buying all the parts to build a new machine), so I apologize if this is already mentioned somewhere in the UnRAID UI, but I haven't found it being discussed on the forum anywhere. Right now, the parity drive(s) for UnRAID need to be the largest drives in the array, and if you try to add a new data drive that's larger than your parity drive, UnRAID won't let you do that. I do understand why that's needed - on a data drive that's larger than the parity drive, the storage at the "end" of the data disk wouldn't be protected by parity. But lets assume I have a setup with one 8TB parity drive and two 8TB data drives each, and the data drives are at capacity and I need additional storage NOW, as fast as possible. I run to the store and grab a new 12TB drive (or whatever size is currently cheapest in terms of $/TB), and then I would either need to throw away my parity and re-build it on the new 12TB drive (giving me three 8TB data drives and one 12TB parity drive), or I would need to migrate the parity data to the new drive. Both solutions are not ideal - the first one means my array is entirely unprotected until the parity is rebuilt and if a drive dies, I'm screwed. And the second solution means it's going to take a long time to copy / migrate the parity data, probably even with a long-ish downtime, and I cannot use the additional storage immediately - I would need to wait until the parity move is over. However, just by looking at the documentation about how UnRAID works, there should be a theoretical third solution, which I haven't found anything about online. I believe UnRAID currently doesn't support that, so that's why I'm writing this post. Assuming I have an array with 2x 8TB data and 1x 8TB parity - what if it was possible to add the new 12TB drive as an additional data drive, but have UnRAID limit all writes to that drive to the first 8TB? Create an xfs partition that's just 8TB and ignore the rest. That'd mean my new 12TB data drive would act like it was just an 8TB data drive, with the last 4TB unused / unavailable. But it would also mean I'd get an additional 8TB of usable storage *right now* without having to mess with parity. And then in the future I have all the time in the world to get yet another new 12TB drive, migrate the existing 8TB parity drive to a new 12TB parity drive, and at that point unRAID would recognize "Hey, the parity drive is now larger, that means I can now unlock/use the last 4TB on that data drive by resizing the file system". Basically, it would mean that you could *add* data drives to your array which are larger than your parity drive, but you'd only be able to use the same amount of space that your parity drive has. Am I missing something that makes this not work as I described? Or is this just not implemented in UnRAID for whatever reason? I'm not saying I absolutely need this feature, but it would be nice to be able to expand an array with a larger data disk, even if it means I cannot use 100% of it (until I get a larger parity drive).