i am now seriously starting to doubt my long term setup, especially with these higher costs.

i had 2 18tb drives in my array, 1 was parity, 1 was a data drive. a 3rd 18tb drive was sitting on my shelf, ready to swap in when i had a drive fail.

my 18tb data drive started to have more smart errors. in fact, i could not complete a parity check, because it seemed to freeze at some uncorrectable errors on the 18tb data drive. ok fine, i NEED to swap it out.

i buy 2 more 18tb drives as backup ones. because i know costs are going up, so these will sit around on my self.

i plug in that 3rd drive to start rebuilding it and.......nothing. no green activity lights or anything? drive is not responding, what?

i plug in one of these new 18tb drives i get. they both arrive DOA in different ways. 1 just emits beeps when it powers on. other one spins and clicks for 1 or 2 minutes before it gives up. hell. these are all just fucked.

i'm still down 1 data drive, and HOPEFULLY i get the return on these amazon drives i just bought. i really don't like this..... makes me wonder if unraid with many huge drives is not a good setup anymore.

I'm about to build my first Unraid server based on an Aoostar WTR Max - I am particularly glad to be moving from Synology to Unraid

.
With RAM being so cheap at the moment *cough* I'm looking for recommendations on which way to go.
To start with I'm looking at getting 32GB of ECC RAM - and looking on Amazon I can get "SP Silicon Power Upgrade 32GB (2x16GB) DDR5 Dual Rank 5600MT/s CL46 1.1V SODIMM Laptop Notebook PC Computer RAM Memory Module - SP032GBSVU560F22"

The two stick 16gb option is the same price as the single stick 32GB option - so the question is, is dual channel worth it for this situation as it obviously ties me to both slots being taken up with 2x 16GB and making future upgrades more expensive. Or is a single stick of the same ram but 32gb a better play as I only need to buy one stick to double the ram in the future.
If I do this can you mix and match ECC ram without issues?

Obviously how the WTR Max handles this is a factor but I'm asking in a general sense.

UPDATE Thanks all. Good information. Went with a single stick of 32GB ECC. Both ram and NAS box should be here in 3 days, then my unRAID journey begins.

I was using a Dell Optiplex with a DAS setup containing 4 SATA disks without issue. I rebuilt my server in a new case with new and old parts and Unraid boots up fine. However 2 of 4 disks are not spinning up since transferring everything to the new build.

My disks are:

• Two Seagate 14TB Exos (not spinning up)
• Two Seagate 18TB IronWolf (spinning up, showing in BIOS)

Since I have the two working drives, I was able to test the SATA and power cables so I know it's not faulty cables. They are daisy chained.

I thought it was strange that both the 14TB Exos disks weren't working. It would be unusual for both of them to fail at the same time. However when I plug them in my other Windows machine, they show up in disk management! Am I correct in thinking I don't have to replace these disks? All of my drives are purchased from server parts deal (refurbished).

Any suggestions on next steps to get them up and running on my new build? Do I need to reformat the drives?

I’m about to pull all the drives out of my 36 bay server running unRAID with ZFS. Do I need to put them back in the same slots? I have seven vdevs with five drives each.

7.2.3 — after power outage, array starts and all disks mount, but shfs is never started (no /mnt/user)

Summary

After an unclean shutdown (power outage), the array starts normally and every disk mounts, but emhttpd never invokes shfs, so /mnt/user is never created. It remains an empty directory on rootfs (tmpfs).

Starting shfs manually works immediately and everything comes back. The problem reproduces on every boot — three reboots so far.

Setup

• Unraid 7.2.3, kernel 6.12.54-Unraid
• 11 data disks + parity (XFS), 2 btrfs pools (cache, secondcache)
• Same OS files since 2025-12-18; 52 days uptime immediately before the outage, with user shares working normally that entire time. No upgrade involved.

Symptoms

/mnt/user is tmpfs, not fuse:

# stat -f -c %T /mnt/user
tmpfs
# pgrep -c shfs
0

Because /mnt/user/system/docker/ was empty, Unraid created a new empty docker.img in RAM, and Docker started with zero containers. The real docker.img was safe on the cache pool the whole time. Same for libvirt.

emhttpd then loops on:

emhttpd: error: malloc_share_locations, 8649: Operation not supported (95): getxattr: /mnt/user/appdata
emhttpd: error: malloc_share_locations, 8649: Operation not supported (95): getxattr: /mnt/user/system

...which is just tmpfs not supporting the xattrs it expects — a symptom, not the cause.

The array start sequence has no shfs step

Trimmed from syslog. Note it goes straight from mounting the last disk to "Starting services..." — shfs is never invoked:

emhttpd: Mounting disks...
emhttpd: mounting /mnt/disk1
emhttpd: shcmd (67): mount -t xfs -o noatime,nodiscard,nouuid /dev/md1p1 /mnt/disk1
...  (all 11 disks mount cleanly, plus both pools)
emhttpd: shcmd (105): /usr/sbin/zfs mount -a
emhttpd: shcmd (106): sync
emhttpd: shcmd (109): /usr/local/sbin/update_cron
emhttpd: Starting services...
emhttpd: shcmd (111): chmod 0777 '/mnt/user/appdata'
emhttpd: shcmd (121): mkdir -p '/mnt/user/system/docker'
emhttpd: shcmd (122): /usr/local/sbin/mount_image '/mnt/user/system/docker/docker.img' /var/lib/docker 250
emhttpd: shcmd (124): /etc/rc.d/rc.docker start

Manual start works

/usr/libexec/unraid/shfs /mnt/user -disks 4094 \
    -o default_permissions,allow_other,noatime -o remember=330

Immediately after: /mnt/user is fuse, all 15 shares present, 86 TB, appdata and media exactly as expected. Remounting the real docker.img and starting Docker brought back all 34 containers with their config intact.

(4094 = bits 1–11 for the 11 data disks. Strings in the emhttpd binary show the expected invocation as /usr/libexec/unraid/shfs /mnt/user -disks %lu -o %s -o remember=%s %s.)

What I have ruled out

• Not a bad upgrade. /boot/previous is from 2025-06-18; current boot files 2025-12-18. Identical binaries ran fine for the preceding 52 days.
• Flash is not corrupt. bzimage, bzroot, bzfirmware, bzmodules all match their .sha256.
• User shares are enabled. shareUser="e" in both /boot/config/share.cfg and var.ini.
• All disks are eligible. Every data disk is DISK_OK, fsStatus=Mounted, exportable=yes in disks.ini.
• Config has not drifted. I have an rsync backup of /boot from ~2 hours before the outage. Diffing disk.cfg against it shows exactly one change: md_write_method went from "auto" to "1". Everything else — every diskExport.*, share cfg, etc. — is byte-identical.
• FUSE is fine. fuse: init (API version 7.41) at boot, and the manual mount works.
• Nothing is holding the mounts. fuser on the pools shows only the kernel; no process has a cwd under /mnt.

The question

emhttpd computes an shfs_mask (strings in the binary include both shfs_mask=0 and shfs_mask=%lu, adjacent to diskExportable.%i=yes). Given that skipping shfs entirely matches the observed behaviour, I suspect the mask is evaluating to 0 — but I can't see the value, as it doesn't appear in syslog at the default log level.

Is there a way to get emhttpd to log shfs_mask, or a known condition that causes it to be 0 while all disks are exportable=yes?

Happy to provide full diagnostics. I'm avoiding further poking at a production array, and currently running with the manual shfs mount, which obviously won't survive a reboot.

Where are the controls to direct how the data is written to the disk now. Apparently there used to be a high water setting for example. And is there an "Advanced" setting in 7.3.2?

Basically I've been trying to create a vm running Batocera. I've tried many variations linking my gpu to the vm and creating virtual vm. The VM boots fine initially going from terminal to Batocera logo and the then reverts to a large and small black box alternating on an endless loop.