_cjd_

@tjb_altf4 Those are VLANs eth0.4 and eth0.5 and are working. And they show in network settings attached to eth0. I did also already completely remove all docker network assignments and re-add them, which caused eth3 to become available for docker, noted above. I will approach from the network side and completely redo all of that though, first again removing everything from docker. I just am at a loss where random bogus config (possibly just old? That's my hypothesis here, it's all old config; the share issue certainly was) could appear as a result of the upgrade.

Completely removing all networks for docker config, then re-adding them all has brought eth3 back, but still not eth0. Also, I can no longer connect to SMB shares... That was working after the update, but possibly broke with me twiddling share config files to fix the messed up one? edit: solved, I had renamed the bogus share config to a non .cfg extension and it seems that caused issues; removing it and shares are all working again.

I've also now discovered a share (/Music) which regressed to very old configuration, but had a weird copy .cfg in the flash /config/shares folder. Was able to fix that with some renaming. docker.cfg in /config has very wrong data, it's still trying to enable bond1 eth0_4 and eth0_5, and I can't figure out where it's getting that. There is no bond1. Can't manually edit this? I tried to update the list manually and it regressed soon as I restarted the docker service. Still trying to figure out a solution.

Should also note, syslog shows that docker can not find these interfaces. I've tried removing them and re-adding them in the docker settings.

Even more bizarre - my backup server (which I updated first, but doesn't typically run dockers) still presents eth0 etc as available interfaces for Docker! I've cross-checked network and docker settings and they're the same except there are no VLANs on the backup server at the moment... testing whether adding one breaks this. I can not repro this issue on the backup machine. I've added VLANs as well as ipv4+ipv6 and can still choose from among the custom networks including eth0 and eth0.5 when defining docker config.

Custom VLANs work, but eth0, eth3 are unavailable. I've gone through all the settings I'm aware of trying to figure out what's going on and find nothing; nor anything in the release notes that obviously points to what's going on here. Will have to roll back if there's not a quick fix someone can help point me to. Available options: Bridge Host Container None Custom : eth0.4 Custom : eth0.5 List of interfaces defined in Docker config: Attaching diagnostics. diagnostics-20251031-1450.zip

Most things seem to have updated smoothly. Unfortunately, it seems I'm no longer able to bind dockers to networks properly (eth0/eth3 both disappeared, VLANs still show). Nothing in the release notes prepared me for this, and I can't find any settings yet to resolve. Topic for this issue:https://forums.unraid.net/topic/194672-unable-to-bind-docker-to-custom-interface-eth0-after-72-upgrade/

The packet loss only one direction might indicate a cabling issue, nic issue, or perhaps that MTU tuning is required. Or something else entirely. What are your MTU settings? Cabling you may be able to try some single port testing and cable swapping at least. Possibly also nic/port testing this way. The chatgpt summary is not particularly helpful to me, but it seems like a reasonable analysis assuming it's trustworthy and that's what the data says.

"The run" is what exactly? Let's try just one question at a time. Please run iperf3 server to server and share the results.

What kind of backup? Macrium for Windows, time machine for Mac. Duplicati for server shares. User scripts/rsync for full unraid backup to a second unraid server. Off-site is a work in progress but right now is just raw files to an external HDD, critical data files only. I also have urbackup but am about to ditch it, it just freezes when I try to actually work with backups. Backups you can't access are worthless...

What up does iperf server to server say? What does one ffsync alone with large files achieve? I can't think of an easy way to dedicate a nic to a docker unless they're on different networks. I still suspect multiple parallel writes will hit limits due to head movements required. The above two bits for info may help isolate what's holding things back.

I may be failing in my search-fu today but not finding a clear answer: is anyone managing higher than c3 with ipmi installed? I am on 4101 bios as 4302 was reported to have issues with c states. Onboard Ethernet disabled. I found one USB device preventing even c3, removed for now. 5x Ultrastar 16tb hdd. 2x mx500 sata SSD, 1xm.2 980pro, x710da2 nic (DAC to switch)... Can't break a mean of 35w idle. Triple checked bios settings, have the Intel GPU drivers installed. Really don't want extended down time chasing things unless it's not ipmi for sure. In hardware breakin testing I was hitting 22w without the GPU drivers, 1x onboard Ethernet, and with a different m.2 and only 2 SSD, no hdd. I didnt pay enough attention as it idled where I expected to be so didn't chase it, should have tested further there I guess.

What speeds are you observing? In the end you'll still be write speed constrained I think. That assumes your network is optimized, jumbo frames etc. If your disks can sustain higher write speeds (and also read speeds in this case) than a 10gbe connection, link aggregation may help on the 10gb side. Assuming your 500Gb is read speed and a typo, interpreting as 500Mb/sec and in RAID5, that's only 30% faster max read than optimized 10Gbe. All theoretical maximum. If I'm doing my math right, lots of assumptions being made... I'd be surprised to see write speeds saturating in practice, though large files may manage. Anything that isn't using all the 2x18 in RAID5 will be write speed constrained. Any parallel operations will slow things overall in a full RAID scenario and be write speed constrained.

I'm still waiting on CPU to assemble but I think I took a power surge and have instability in my amd (x570-d4u 5600x) and decided reluctantly to try Intel - though I'll use the igpu for llms not transcoding (not tequired here). Went asus ws-680-ace ipmi, 14500 for cpu, 64gb ecc. My amd idled around 41w, hoping this'll do better. 5x hdd, 2 ssd, 1 m.2, x710-da2 nic sfp+/dac (on oard ethernet ignored, can't disable).

I idle with a mean 41W. X570d4u includes IPMI which adds some, as does an external USB monitoring my home power meter. 32gb ecc, 5600x, x710-da2 (DAC to switch, Ethernet is more power hungry), 5hdd, 3ssd, 1 m.2 (Samsung 980 pro at the moment) with dockers (home assistant, influxdb and a bunch more always running). When I needed an ASM1166 for more drives idle was up 2-4W. There are 11 fans and it ran 1w+ lower end of the winter when an SSD failed and I dropped to the 8 I have now. You don't need Xeon for ECC. I'm considering a reluctant switch to Intel for llm on the igpu. Power consumption would take decades to pay for itself, if it's even lower.

You should be able to tune idle power consumption lower (unless you're not spinning down drives). Also vaguely considering a switch to a very similar build, just have to justify the expense and that's hard...

Finally found time to start fresh and indeed, the problem was a missing keyfile *at the time of format* - simple and obvious in hindsight but in the heat of frustration over hardware failed suspiciously and for no apparent reason, that clear view is always tough to find. Appreciate the responses and the point in the right direction. Simply rebooting w/o deleting the keyfile on boot doesn't encrypt an already-formatted drive though - hoped it might since it was formatted understanding it was to be encrypted, but no go.

Ooh, yes! That actually seems rather likely the cause. Just need to find a minute to babysit a reboot. Can't believe it didn't occur to me.

I can try clearing externally. I thought doing so in unraid would do the trick. Thanks for the suggestion. The other encrypted drives are all still working/decrypting fine.

TL;DR new RAID1 pool created. No partitions. `btrfs encrypted` selected as format, applied. No formatting happened prior to doing this. drives formatted *after* setting btrfs encrypted. Reference docs used after the first try failed (I've gone through this multiple times thinking I missed a step) The system has been rebooted. First try, within an hour of creating the pool. Second time after a long wait (24h I think?) The pool remains on "Drive to be encrypted" with an orange padlock icon (screenshot attached for reference). The first time I rebuilt the cache I forgot about setting the format and saw a different version of this icon (shackle swing left of the body, vs over it). Longer version Due to a power loss, UPS sent server into graceful shutdown. On the first boot after, two of the four 2TB ssds in a RAID10 pool were missing, and seem to be completely dead - no system recognizes them at all. That's a different saga, as they're the two WD Red SA500; Crucial MX500 drives are fine. But... I seem to have had the WDs in the same slot in the array (or I made mistakes) as nothing I did allowed it to be recovered. Data backup/recovery went fine so no real loss other than time there (and wondering why I bothered with the mirror set at all). However, as part of this I did end up rebuilding the pool with just a RAID1 on the pair of 2TB still working. I've migrated from unencrypted to encrypted drives in the past, and even did a rebuild from RAID1 to RAID10. These all start with a new pool on emptied drives (no partitions etc). I've gone through this process multiple times and it's always worked. This time around, it doesn't. What am I missing? Diagnostics also attached in case those are helpful. diagnostics-20250428-1059.zip

Coincidentally I just lost two of four in a RAID10 pool - both wd red 2tb, the other two are crucial mx500 2tb. Unfortunately it seems they were the same part of the mirror (or I did something wrong) as the pool was toast. Completely dead drives, no system recognizes them. Power loss and UPS triggered graceful shutdown, and they never returned - gone on boot. Backups restored fine though.

Most of my dockers are directly receiving ips on their assigned vlan (macvoan setup). No custom bridge. I've had as many as four physical interfaces (all different vlans) and tried other approaches but cut two for power saving (dial sfp+ is more than enough bandwidth). This has been the most stable as well.

Unraid needs an IP on the nic in order to route through it, unless perhaps it's assigned to a VM and not used for dockers. Otherwise you can just segment multiple vlans on the sfp+.

Workstation boards for Intel support ECC. Asus W680-ace (3 variants) just as an example. With better c-state range and more they tend to be able to tune for lower idle power consumption too. Also these boards get you into IPMI. Is a supermicro option with the same chipset. I run an asm-1166 SATA expander board (more power efficient than hba) and I think plenty of others do similar. I don't recall anything about splitting the array.depending how big your array gets, and HBA may still make sense. That was just food for thought. And... Water cooling adds failure modes, some of which can be catastrophic if you're not watching things. I won't even run it in my SIM rig, preferring good airflow and a giant tower cooler. Maybe I'm just a skeptic needing to learn about the latest...

For a NAS almost none of this build immediately makes sense. So let's start with intended usage. What are your plans? Strongly recommend against liquid cooling in a server. Failure modes are more catastrophic for a system you mostly ignore but leave on all the time, cost is higher, and function unlikely to make any difference at all. Just no good reason, and a number of good reasons to not. The rest is more reaction/thought than anything. There are likely better price/TB drives to choose but that may be location dependent. I've been seeing new Exos 20tb at us$18/TB. I haven't wanted longer parity checks so sticking with 16 myself. Do you care at all about power consumption? Given the added GPU, why not an Intel build and use the igpu? I don't see a reason for hba at 6 drives. Pick a board with enough SATA for the planned 6 drives. Not up to speed on consumer boards (gaming rigs aren't up for an update and servers I want IPMI so end up with server boards) but Wi-Fi seems silly. Maybe impossible to avoid. Not a case I'd ever use (airflow)...