Hello,

To give some context, i'm not at home at the moment and I've been facing what might be a power outage on my unraid server. I did log back few hours ago, start a parity check because it was not a healthy shutdown. Then the server became unresponsive few hours later but in fact I was able to see it was connected to the network, usually i'm loogin through ip:8888 but it's now just ip and the name change from its name to Tower (like default name) and the two NVME usually mount as cache are appearing as unmount in the interface. I don't know what to do ?

Any suggestion I'm a bit worried, I ask AI of course and it says it could be an issue with the flash drive.
But I prefer to ask experienced users of course before taking any action.

The server name reverting to 'Tower' definitely indicates that Unraid had problems reading the name you defined for the server from the flash drive.

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread.

It is always a good idea to do this to allow us to see the current state of your system and so we can see logs and configuration information.

Thank you for your answer, I've attached diagnostics

tower-diagnostics-20260928-0031.zip

The diagnostics point to lost or damaged configuration on the USB flash drive. There are recovered-file artifacts on the flash, the server settings contain Tower and port 80, and the cache pool has no assigned devices.

Both Crucial NVMe drives are still detected as members of the same Btrfs filesystem. Neither reports media-integrity errors. This is encouraging, although it does not yet confirm that the pool can mount or that all its data is intact.

For now, please leave the array stopped. Do not format either SSD, run New Config, or run filesystem repair commands.

Save a current flash backup through Main → Flash → Flash Backup, and keep any older backup separately. Do you have a flash backup from before this happened?

For the pool, reimporting should work:

on main click on the first device for that pool and then "remove pool"

back on main, create a new pool with the same name and number of slots

assign the pool devices, leave the filesystem set to auto

start the array to import the pool

Since you are away, avoid rebooting or removing the flash until someone can assist locally.

Separately, the logs show repeated requests to your login page from public internet addresses. Are you accessing the server through a VPN or direct port forwarding? If the WebGUI is directly exposed, arrange VPN access (https://docs.unraid.net/unraid-connect/remote-access/) before removing that forwarding rule.

Thank you for the advice,

The array seems fine, I did assign the nvme to the cache pool then start the array with a parity check as usual when an unhealthy shutdown happen. I did save the flash usb.
I'm using a VPN to connect to the webgui usually the :8888 is not exposed to internet but as it reverted to default config the :80 was exposed behind a swag docker container.

I have a previous flash backup (30/08) but I did that before upgrading to 7.0.1.
I'm back at home in 5 months so I won't be able to replace the flash drive if it's what is faulty there.
The parity check is a 30% right now.

I have two questions :

• How can I check remotely if the flash drive has an hardware issue ?

• With my old backup how can I check the diff as the config has been partially set back to default, I've only identified the name and the port of the webui

Is there something I need to focus on ?

Good to hear the array and pool are back.

You can't fully confirm flash health remotely, but these read-only checks will show whether the flash can still read cleanly:

- The flash backup you made worked, so every file on the flash could be read. That's a good sign.

- Run a full read of the device. The flash was sda in your diagnostics; confirm this on the Main page first:

dd if=/dev/sda of=/dev/null bs=1M status=progress

dmesg | grep -iE "i/o error|fat-fs"

- Check the filesystem without changing anything (-n only reports; it doesn't repair):

fsck.fat -n /dev/sda1

If both are clean, the flash is usable for now. The two FSCK0000.REC/FSCK0001.REC files show that its filesystem was repaired at some point, most likely after the power loss. They don't prove the device is failing. You can only prove write reliability by the problem not coming back. If errors or new FSCK*.REC files appear, replace the flash when you are home. Until then, make a new flash backup after each settings change. Unraid Connect flash backup can also do this automatically.

Extract the config folder from both backups and compare them with a diff tool such as WinMerge or Meld, or with diff -r on Linux. Your old backup is from before the 7.0.1 upgrade, so expect some harmless differences. Look first for files that are missing from the current backup, or that went back to near-default content. In the diagnostics, ident.cfg, disk.cfg and the pools folder were all rewritten during the boot with the problem.

Don't copy super.dat or pools/*.cfg from the old backup. Your current array and pool assignments work, and those files would replace them. For everything else, it's safer to set the values again in the GUI than to copy the files back. The two .REC files are 8 KB fragments. You can open them in a text editor and they may show which file they came from.

Things to check:

- Settings → Management Access: set the port back to 8888, and check the HTTPS settings. That way the GUI is no longer reachable through SWAG on port 80.

- Shares: check each share's settings, especially primary and secondary storage and mover settings, now that the pool was recreated.

- Docker and VM Manager: check the settings and paths, and that the containers and VMs start normally.

- Users and SMB/NFS settings: check users and share export and security settings.

- Date & Time: NTP was off and should probably be on. Also check the time zone.

- Notifications, and any plugin settings you rely on.

When the parity check finishes, please post new diagnostics. We can then confirm the pool is mounted correctly and check the current config files.

The parity check did finish, restored the port back to 8888, in the previous configuration the SWAG container was displaying a dummy page on 80 and 8888 wasn't exposed outside the local network.
Pool seems to be mounted correctly and my wife called an electrician to repair something (might be the original cause of the outage) on our electrical network at home. So I did shutdown the NAS before the electrician did some work on the electric installation. It doesn't boot properly anymore. I'm screwed .

olivia-diagnostics-20260929-0043.zip

Edited Wednesday at 01:21 PM3 days by erqz

Were these diagnostics collected before you shut down for the electrical work, or after the boot problem started?

They show that the cache pool mounted with both devices and the parity check completed with zero errors. At collection, Unraid was running, but the array was stopped.

When you say it “doesn’t boot properly,” what happens exactly? Does it stop at an error on the monitor, does the WebGUI fail to open, or can you access the WebGUI but cannot start the array?

If it stops during boot, ask someone at home to photograph the monitor. If these diagnostics were collected after the problem started, how did you collect them?

Sorry for being not really clear.
I collected the diagnostics after parity check and brought back the cache pool. Then I stopped the array and shutdown the server for electrical work.
Now the server is running but it doesn't connect to the network (i can check the routeur connected devices/dhcp) so I can't access anything from remote and there is no screen connected to the server and it will be too complicated for my wife to connect a screen and give a picture of the error on boot.
I just ask her to confirm the green led is showing through the case window, it's the max I can ask her
So it's running (under power) but it does'nt behave as usual.

Thanks, that clarifies the sequence. Those diagnostics show the recovered system before shutdown, so they cannot explain what happened afterward.

The green LED confirms that some power is present, but it does not confirm that Unraid booted. The missing router entry alone also cannot distinguish a boot failure from a network problem.

If your VPN still provides access to the home network independently of this server, try its previous IP address on port 8888. Also check the router for a changed address. If the server uses a static IP, it might not appear in the DHCP lease list.

If the router or switch shows Ethernet port status, check whether the server’s port has a link.

If those checks do not locate it, we have reached the limit of remote diagnosis without console access. I understand that connecting a monitor is not practical for your wife. Someone comfortable with the hardware would need to inspect the boot screen and network connection.

I would avoid repeated forced restarts or changing the flash blindly. Nothing in this update establishes that the array or cache data was lost.