Searched the forums, and it suggested checking the cables to the drives, so I did that.

Restarted the server and when it came back up, I then saw the drive in Unassigned Devices.

Found instructions to bring that drive back into the array, with the first step being to stop the array. It's here where I got stuck on "Array Stopping•Retry unmounting disk share(s)..."

I have tried following workarounds on a couple of threads from the forums, but these do not seem to have helped and I am still stuck with the array attempting to stop.

https://forums.unraid.net/topic/145821-cant-unraid-stop-when-array-already-unmounted/

https://forums.unraid.net/topic/141479-6122-array-stop-stuck-on-retry-unmounting-disk-shares/

Also spotted cache disk doesn't appear to show in the UI anymore, and key file is missing.

Diagnostics attached.

Console output also included below in case it helps to see what's been tried:

root@Nebula:~# umount /var/lib/docker
umount: /var/lib/docker: target is busy.
root@Nebula:~# lsof /mnt/cache
lsof: status error on /mnt/cache: No such file or directory
lsof 4.93.2
 latest revision: https://github.com/lsof-org/lsof
 latest FAQ: https://github.com/lsof-org/lsof/blob/master/00FAQ
 latest (non-formatted) man page: https://github.com/lsof-org/lsof/blob/master/Lsof.8
 usage: [-?abhKlnNoOPRtUvVX] [+|-c c] [+|-d s] [+D D] [+|-E] [+|-e s] [+|-f[gG]]
 [-F [f]] [-g [s]] [-i [i]] [+|-L [l]] [+m [m]] [+|-M] [-o [o]] [-p s]
 [+|-r [t]] [-s [p:s]] [-S [t]] [-T [t]] [-u s] [+|-w] [-x [fl]] [--] [names]
Use the ``-h'' option to get more help information.
root@Nebula:~# lsof /var/lib/docker
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
dockerd   8180 root   13u   REG   0,47    32768     293 /var/lib/docker/volumes/metadata.db
dockerd   8180 root   19u   REG   0,47    16384    5689 /var/lib/docker/buildkit/containerdmeta.db
dockerd   8180 root   20u   REG   0,47    16384     304 /var/lib/docker/buildkit/snapshots.db
dockerd   8180 root   21u   REG   0,47    16384    5690 /var/lib/docker/buildkit/metadata_v2.db
dockerd   8180 root   22u   REG   0,47    32768     309 /var/lib/docker/buildkit/cache.db
dockerd   8180 root   28w   REG   0,47   433199 1023963 /var/lib/docker/containers/7eab7a44d5f408d3a06712bfd9716239e245a76bb6cd60aa850fadf5c4e0dfed/7eab7a44d5f408d3a06712bfd9716239e245a76bb6cd60aa850fadf5c4e0dfed-json.log
dockerd   8180 root   34w   REG   0,47 31724307 1360831 /var/lib/docker/containers/63f3828ac3d799f8a4f894e49a33bfba7e0057bdfc722cac272f684289aaa11d/63f3828ac3d799f8a4f894e49a33bfba7e0057bdfc722cac272f684289aaa11d-json.log
dockerd   8180 root   40w   REG   0,47 32079446 1275318 /var/lib/docker/containers/bdd9b652e9b0032f28a64db857cfce965e27e302f794e65ee4d415b6417f1266/bdd9b652e9b0032f28a64db857cfce965e27e302f794e65ee4d415b6417f1266-json.log
dockerd   8180 root   43w   REG   0,47    25224    7963 /var/lib/docker/containers/e79ef2ed99dcf1aa372fc5c208fabe7462199a253a1009c8bf09925319999aa2/e79ef2ed99dcf1aa372fc5c208fabe7462199a253a1009c8bf09925319999aa2-json.log
dockerd   8180 root   51w   REG   0,47 19761177 1019027 /var/lib/docker/containers/6bd8577a078676c766e55153002bd82ea82a8c29d329fe3c76dac82ac99749a8/6bd8577a078676c766e55153002bd82ea82a8c29d329fe3c76dac82ac99749a8-json.log
dockerd   8180 root   57w   REG   0,47 47846993 1326681 /var/lib/docker/containers/04f5a25174258a0a9c0ab2179c881246204884e0dcaa758967e217d3873a434a/04f5a25174258a0a9c0ab2179c881246204884e0dcaa758967e217d3873a434a-json.log
container 8195 root    4u   REG   0,47   524288     272 /var/lib/docker/containerd/daemon/io.containerd.metadata.v1.bolt/meta.db
root@Nebula:~# losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                           DIO LOG-SEC
/dev/loop1         0      0         1  1 /boot/bzfirmware                      0     512
/dev/loop2         0      0         1  0 /mnt/disk1/system/docker/docker.img   1     512
/dev/loop0         0      0         1  1 /boot/bzmodules                       0     512
root@Nebula:~# umount -l /dev/loop2
root@Nebula:~# lsof /var/lib/docker
root@Nebula:~# losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                           DIO LOG-SEC
/dev/loop1         0      0         1  1 /boot/bzfirmware                      0     512
/dev/loop2         0      0         1  0 /mnt/disk1/system/docker/docker.img   1     512
/dev/loop0         0      0         1  1 /boot/bzmodules                       0     512
root@Nebula:~# lsof /mnt/disk1
root@Nebula:~# lsof /mnt/cache
lsof: status error on /mnt/cache: No such file or directory
lsof 4.93.2
 latest revision: https://github.com/lsof-org/lsof
 latest FAQ: https://github.com/lsof-org/lsof/blob/master/00FAQ
 latest (non-formatted) man page: https://github.com/lsof-org/lsof/blob/master/Lsof.8
 usage: [-?abhKlnNoOPRtUvVX] [+|-c c] [+|-d s] [+D D] [+|-E] [+|-e s] [+|-f[gG]]
 [-F [f]] [-g [s]] [-i [i]] [+|-L [l]] [+m [m]] [+|-M] [-o [o]] [-p s]
 [+|-r [t]] [-s [p:s]] [-S [t]] [-T [t]] [-u s] [+|-w] [-x [fl]] [--] [names]
Use the ``-h'' option to get more help information.
root@Nebula:~# ls
root@Nebula:~# mkdir tmp
root@Nebula:~# ls
tmp/
root@Nebula:~# cd tmp
root@Nebula:~/tmp# dd if=/dev/zero of=disk2 bs=1M count=310
310+0 records in
310+0 records out
325058560 bytes (325 MB, 310 MiB) copied, 0.291545 s, 1.1 GB/s
root@Nebula:~/tmp# ls
disk2
root@Nebula:~/tmp# mkfs -t xfs disk2
meta-data=disk2                  isize=512    agcount=4, agsize=19840 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=79360, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=1368, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
root@Nebula:~/tmp# ls
disk2
root@Nebula:~/tmp# cd disk2
bash: cd: disk2: Not a directory
root@Nebula:~/tmp# cd ..
root@Nebula:~# ls
tmp/
root@Nebula:~# cd ..
root@Nebula:/# ls
bin/   dev/  home/       init@  lib64/  opt/   root/  sbin/  tmp/  var/
boot/  etc/  hugetlbfs/  lib/   mnt/    proc/  run/   sys/   usr/
root@Nebula:/# cd mnt
root@Nebula:/mnt# ls
disk1/  user/
root@Nebula:/mnt# mkdir disk2
root@Nebula:/mnt# ls
disk1/  disk2/  user/
root@Nebula:/mnt# cd ..
root@Nebula:/# cd tmp
root@Nebula:/tmp# ls
ca.backup2/  community.applications/  emhttp/  notifications/  plugins/
root@Nebula:/tmp# cd root
bash: cd: root: No such file or directory
root@Nebula:/tmp# cd ..
root@Nebula:/# ls
bin/   dev/  home/       init@  lib64/  opt/   root/  sbin/  tmp/  var/
boot/  etc/  hugetlbfs/  lib/   mnt/    proc/  run/   sys/   usr/
root@Nebula:/# cd root
root@Nebula:~# ls
tmp/
root@Nebula:~# cd tmp
root@Nebula:~/tmp# ls
disk2
root@Nebula:~/tmp# mount disk2 /mnt/disk2
root@Nebula:~/tmp# 

nebula-diagnostics-20260717-0945.zip

Edited Friday at 08:51 AM5 days by gooner_47

Jul 17 09:45:10 Nebula kernel: FAT-fs (sda1): Directory bread(block 32774) failed

Jul 17 09:45:10 Nebula kernel: FAT-fs (sda1): Directory bread(block 32775) failed

Jul 17 09:45:10 Nebula kernel: FAT-fs (sda1): Directory bread(block 32776) failed

Jul 17 09:45:10 Nebula kernel: FAT-fs (sda1): Directory bread(block 32777) failed

The flash drive is having issues; you can try recreating it first, then post new diags after array start.

To recreate the flash drive, first backup the current one, then recreate it using the USB tool, confirm the flash drive boots with the stock install, and if yes, restore only the /config folder from the backup overwriting any existing files.

Presumably this all needs to be done with the server off.

It is currently still trying to stop the array, am I able to/is it safe to power off the system while in this state?

When I go to create a "Flash Backup" the screen turns white and nothing happens:

Edited Friday at 10:21 AM5 days by gooner_47

You need to shut down the server (by force if needed) and manually try to backup the flash drive, just need to try to copy the existing /config folder; all you need is there

ok thanks, will do.

do the logs indicate a potential issue with the flash drive itself? i.e. should i buy a replacement to rebuild? or is it safe to just attempt a rebuild on this existing flash drive

It's fine to attempt to recreate the existing one first; if that doesn't work, repeat with a new flash drive, but you will then need to transfer the key.

if that doesn't work

How might you expect that not to work, exactly?

I made a backup of the usb, downloaded the USB tool and used it to recreate a bootable drive. I also ran make_bootable_mac because my motherboard is ancient.

When I reinserted this in the server, and started it up, I only get as far as a PCI Devices list and it never actually boots.

Attempts to hit F12 to enter the boot menu and select the USB HDD option do not work, it simply reverts to the same screen. Also entering the BIOS setup, and changing the first boot device to USB-HDD, saving and restarting also does not help, I never get further than the PCI Devices list screen.

I don't see any reported issues with the usb in disk utility, it seems to just behave normally.

Edited Friday at 09:43 PM5 days by gooner_47

9 hours ago, gooner_47 said:

I only get as far as a PCI Devices list and it never actually boots.

Is that with with a stock install?

21 hours ago, JorgeB said:

To recreate the flash drive, first backup the current one, then recreate it using the USB tool, confirm the flash drive boots with the stock install, and if yes, restore only the /config folder from the backup overwriting any existing files.

Yes, that’s with a stock install. Nothing was copied over from the backup. I only ran make bootable mac

That suggests either a flash drive issue, or a compatibility issue between the server and the release you installed. If you are using a newer Unraid release, try recreating the flash drive with a version that is known to work with that server, if it still fails to boot, post a photo of where it stops.

The compatibility point could be the one, as I know the version I installed on the flash was the latest (just selected the recommended/default option), and I was on 6.9.2.

I will try this again tonight and report back.

Ok so I created a new flash drive with v6.9.2. Ran make bootable mac again. Inserted it into the server and booted up, and I got stuck on the same screen.

First boot:

F10 then select USB-HDD ends up going back to the same screen:

All BIOS pages in case there's anything in there:

Flash drive contents:

That looks like the board is not even trying to read the flash drive; try booting it on a different PC to confirm it's working.

It looks as though the board may be borked. I used the original flash drive in another machine and was able to boot from it and get to the Unraid installation screen.
I also borrowed another, new USB drive to try in the server and no matter how much I tried I could not get it to boot from it. Tried:

• using the tool to make the flash drive

• using the tool to make the flash drive then running make_bootable_mac

• manually creating the flash drive by formatting as FAT32 then unzipping the unraid OS contents

• manually creating the flash drive by formatting as FAT32 then unzipping the unraid OS contents, then running make_bootable_mac

Closest I could get to the server doing something was actually seeing the new Lexar flash drive in the boot priority list, but selecting it then did not boot from it, just went to the PCI Devices Listing screen above.

I think the combination of those things does seem to point to a server problem.

With that in mind, what are my options here to get this up and running? Ideally as cheaply as possible.

Edited Tuesday at 07:49 AM1 day by gooner_47

It may be worth trying to do a CMOS reset and/or looking for a BIOS update; if it still fails to boot after that, you may need to use a different board.