For the last several months, every time I go to the WebGUI to login, it has been unavailable. Everything else still running. Can get to shares and apps running in a docker. I have been hard powering the machine to get it up and running so I can login when needed. I recently got fed up with this and decided that I would enable SSH so that I could ssh to it and restart it cleanly. SSH is not responsive when the WebGUI is not responsive so no real help there. Then 7.2.3 was released so I updated hoping that there was a hidden bug fix.

Today, I finally bit the bullet and climbed under the desk and plugged in a monitor and mouse when this happened again. I was able to login to the console and found that both the ngnix daemon and sshd were not running. I was able to start them and the GUI and SSH are accessible.

Dec 23 07:52:05 zelda rc.nginx: Updating Nginx server daemon...
Dec 23 07:52:05 zelda rc.nginx: Reloading Nginx server daemon...
Dec 23 07:52:05 zelda rc.nginx: Checking configuration for correct syntax and then trying to open files referenced in configuration...
Dec 23 07:52:05 zelda rc.nginx: /usr/sbin/nginx -t -c /etc/nginx/nginx.conf
Dec 23 07:52:05 zelda rc.nginx: Reloading Nginx server daemon configuration...
Dec 23 07:52:05 zelda nginx: 2025/12/23 07:52:05 [emerg] 781001#781001: bind() to 0.0.0.0:80 failed (98: Address already in use)
Dec 23 07:52:05 zelda nginx: 2025/12/23 07:52:05 [emerg] 781001#781001: bind() to 0.0.0.0:443 failed (98: Address already in use)
Dec 23 07:52:05 zelda nginx: 2025/12/23 07:52:05 [emerg] 781001#781001: bind() to 0.0.0.0:80 failed (98: Address already in use)
Dec 23 07:52:05 zelda nginx: 2025/12/23 07:52:05 [emerg] 781001#781001: bind() to 0.0.0.0:443 failed (98: Address already in use)
Dec 23 07:52:06 zelda nginx: 2025/12/23 07:52:05 [emerg] 781001#781001: bind() to 0.0.0.0:80 failed (98: Address already in use)
Dec 23 07:52:06 zelda nginx: 2025/12/23 07:52:05 [emerg] 781001#781001: bind() to 0.0.0.0:443 failed (98: Address already in use)
Dec 23 07:52:06 zelda nginx: 2025/12/23 07:52:05 [emerg] 781001#781001: bind() to 0.0.0.0:80 failed (98: Address already in use)
Dec 23 07:52:06 zelda nginx: 2025/12/23 07:52:05 [emerg] 781001#781001: bind() to 0.0.0.0:443 failed (98: Address already in use)
Dec 23 07:52:07 zelda nginx: 2025/12/23 07:52:05 [emerg] 781001#781001: bind() to 0.0.0.0:80 failed (98: Address already in use)
Dec 23 07:52:07 zelda nginx: 2025/12/23 07:52:05 [emerg] 781001#781001: bind() to 0.0.0.0:443 failed (98: Address already in use)
Dec 23 07:52:07 zelda nginx: 2025/12/23 07:52:05 [emerg] 781001#781001: still could not bind()
Dec 23 07:52:08 zelda rc.nginx: Restarting Nginx server daemon...
....
Dec 23 07:53:13 zelda rc.nginx: Restarting Nginx server daemon...
Dec 23 07:53:13 zelda nginx: 2025/12/23 07:53:13 [emerg] 364257#364257: bind() to 169.254.144.100:80 failed (99: Cannot assign requested address)
.....
Dec 22 14:13:17 zelda rc.sshd: Updating SSH server daemon...
Dec 22 14:13:17 zelda sshd[777510]: Received signal 15; terminating.
Dec 22 14:13:17 zelda sshd[779552]: error: Bind to port 22 on 169.XXX.XXX.100 failed: Cannot assign requested address.
Dec 22 14:13:17 zelda sshd[779552]: fatal: Cannot bind any address.

zelda-diagnostics-20251223-0905.zip

I have attached diagnostics.

I'm stumped as to why it is attempting to reload the configuration. And why it is failing but will start when I run the start manually.

Dec 23 08:55:47 zelda rc.nginx: Starting Nginx server daemon...
Dec 23 08:55:57 zelda rc.nginx: Nginx server daemon...  Started.
Dec 23 08:57:02 zelda rc.sshd: Restarting SSH server daemon...
Dec 23 08:57:24 zelda rc.sshd: Starting SSH server daemon...

NIC link is going down/up multiple times, e.g.:

Dec 22 14:12:31 zelda kernel: igc 0000:04:00.0 eth0: NIC Link is Down

Dec 22 14:12:32 zelda dhcpcd[1934]: br0: carrier lost

Dec 22 14:12:34 zelda kernel: igc 0000:04:00.0 eth0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX/TX

Dec 22 14:12:34 zelda dhcpcd[1934]: br0: carrier acquired

It appears to me that this is what is causing the issue, though possibly Unraid should handle this better, but if you resolved the link going down problem, it should also resolve the bind issue.

Nic Down message coincide with the restart on the 21st to upgrade to 7.2.3, ISP outage and restart of the the router on the 22nd, and a reboot of the router on the 23rd to fix a lingering issue.

Are you saying everytime I restart my router, sshd and nginix is going to stop and and not come back up again? This seems less than ideal.

Thanks fore your time looking at this.

8 hours ago, Khanan said:

Are you saying everytime I restart my router, sshd and nginix is going to stop and and not come back up again?

It's not normal, e.g., I can reboot my router without any issues, but I've seen it before. A possible workaround if you need to keep rebooting the router and that is causing the issues, would be having a server on a switch in the middle that is connected to the router; that way Unraid won't lose the link.

Just woke up to these same symptoms, minus any visible NIC bounces. Some docker services were up fine, some were partially usable. VMs appeared to be inaccessible. Ran HDMI and USB cables into the closet and found some IO errors, I assume on the flash drive. (Really wish we could do away with installations to fragile flash media.) Waited a few min for my shutdown attempt then just hit the power switch and yanked the flash drive to make a backup. Hope it's repairable, but I have backups on the array as well.

18 minutes ago, kory1 said:

Just woke up to these same symptoms, minus any visible NIC bounces. Some docker services were up fine, some were partially usable. VMs appeared to be inaccessible. Ran HDMI and USB cables into the closet and found some IO errors, I assume on the flash drive. (Really wish we could do away with installations to fragile flash media.) Waited a few min for my shutdown attempt then just hit the power switch and yanked the flash drive to make a backup. Hope it's repairable, but I have backups on the array as well.

After imaging the drive a filesystem check reported errors, which a repair appears to have fixed. Popped back in the server and booted right up!