Hello,

I am unable to load the main dashboard via dns or ip. I am also unable to ssh to the device on a local network. Services running on the device including Docker and SMB shares are working. This affects the web interface only, leading me to believe there is an nginx issue, but without being able to see the device via web or ssh I cannot confirm.

What next steps should I take and how can I obtain logs in this state?

Since SMB and your containers still work, the server itself is running, and the problem is likely limited to the services that listen on the management IP address (nginx for the WebGUI, and SSH). Before rebooting, please try the following from the local console (keyboard and monitor), logged in as root:

1. Check which services are listening:

ss -ltnp | grep -E ':(22|80|443) '

2. Check nginx:

/etc/rc.d/rc.nginx status

3. Collect diagnostics, it's important to do this before rebooting:

diagnostics

The zip is saved to /boot/logs. If your flash share is exported, you can copy it from \\<server>\flash\logs over SMB, otherwise copy it from the flash drive later.

4. Then try to restart both services:

/etc/rc.d/rc.nginx restart

/etc/rc.d/rc.sshd restart

and check if the WebGUI and SSH come back.

Please post the diagnostics zip, the output of the commands above, and also:

- The exact error from the browser (for example "connection refused" or "timed out") and from SSH.

- Whether a restart of the services fixed it, and if this has happened before.

Hey JorgeB, thanks for the advice!

Here are the outputs and what I was able to gather.

Connected monitor, hit a key on the keyboard and saw this:

Ran the ss ltnp | grep command and saw this:

Ran diagnostics and saw this, ran rc.service reboot and saw this:

Tried a reboot and saw this until I hard reset it with the button:

I am back now as expected and running some updates and things are working well. Should I do a new diagnostics now that it's running?

Almost forgot, here was the original web interface screen before the reboot.

Thanks, those photos are very useful, and they show this was not an nginx problem.

The server lost the ability to read its own OS files. Exit status 135 means a program was killed because part of its file could not be read, and the same problem explains the "Input/output error" on rc.nginx and rc.sshd, and "command not found" for diagnostics. Unraid loads much of the OS on demand from the boot device while it runs, so if that device drops offline or starts returning read errors, anything new fails to start. Things already loaded in RAM, like Samba and your running containers, keep working, which is why SMB and Docker looked fine. The reboot stopped for the same reason, since it could not read the shutdown script, so the hard reset was the right call.

The boot device is the main suspect, but there is no log from when it happened, so this is not confirmed yet.

Yes, please post new diagnostics now. They won't show the failure itself, because the log from that boot was lost, but they will show the boot device and how it is connected, and whether anything is already logging errors.

In the meantime:

1. If you plan to update Unraid itself, make a flash backup first (Main, click the boot device, then Flash Backup), since an OS update writes to that device.

2. If the boot device is a USB flash drive, make sure it is plugged directly into a motherboard port, not a hub or front panel header, preferably a USB 2.0 port if the board has one. Next time the server is off, check that drive on another computer for filesystem errors.

3. The hard reset counts as an unclean shutdown, so a parity check may run when the array starts. If it does, let it finish and tell us if it reports errors.

4. So that we can catch this if it happens again, go to Settings, Syslog Server, and send the syslog to another machine using Remote syslog server. If you don't have one, use Local syslog server with a folder on your array or a pool. Please don't rely on Mirror syslog to boot drive, because that device is the one we suspect, and the lines we need would be lost with it.

If it happens again, a photo of the console is still useful, and the saved syslog should then show what the boot device did. Also let us know if this has happened before, and roughly how long the server had been up.