theJehud

Yeah I think probably where things get weird is somehow the assumed IP of some of the container apps being fixed at *.50 is somehow acting up and taking out Unraids accessibility when the IP changes, which is odd.

I was referring to the unifi dash there in the wired devices it shows but on the settings for that host in unifi, also if I search for that IP in the device list it finds the host showing as *.2 which is super odd I can ping both IPs even though I don't see any device in unifi with a .50. I can't ssh into either still though and nginx gives me a 4XX when I load it on *.2 and works as expected on *.50.

I got it back up but I don't really understand why the previous issues manifested. I had the idea to set the static ip back to what it had been previously before it had gotten reassigned dynamically and that seemed to work let me start the array again. A few of the docker app configs were pointing at that old IP and maybe when it wasn't at that address it caused issues? But I'm not really sure. What is odd, is in Unifi I can see the static ip for that asset is set .50 but it shows up as .2 in the dashboard. I can ping both IPs though successfully even though no .50 shows up in the device client list in unifi. I can't ssh to either IP though and I can see in the UX that the server seems to see itself as the right IP .50 etc.. Attached latest diagnostics. diagnostics-20250224-2116.zip

So I booted it with a screen attached (with the old drive), and logged in to tail the syslog then I mounted the disks from another computer via the dashboard. It seemed to mount the disk fine (in the logs) but then ended with a bunch of errors around nginx failing to bind to ports 80,443 etc.. I don't understand why though unless one of the dockers is conflicting with the main OS but that doesn't really make any sense to me. Does the nginx dashboard start and stop when you mount the arrays or something? I don't get why the dash gets wiped out on array start. The for new drive I made with the utility set to 7.0.0.0 it doesn't seem like it made it a bootable drive, because it doesn't kick in to the boot dialog I'm used to seeing. And just gives a non-system disk error and press any key to restart. If creating from Mac OSX I should be running the make bootable from Mac OSX too right?

So I created a new USB drive that I bought and put these files over from a backup I took, onto the new drive. I did run the make bootable script also after the first boot didn't work just to be sure although the hardware is pretty new. Files Restored from Backup on New Drive ======== config\super.dat config\Plus.key config\pools config\plugins\dockerMan\templates-user I'm running the unraid server headless though, and while the server starts up unraid doesn't seem to boot or become ping'able really. I can hook the computer up to a monitor but not till later in the week probably. At that stage I might be able to just see why the OS crashing with the current set up though. Anything else you can think I should try? Really bizarre this just started happening. I tried to boot with the new drive also without modifying it at all, ie still running make bootable, and Unraid isn't coming up (old drive with problems still boots fine just fails after you array start.).

Parity completed fine, fixed common problems is fine, rebooted(to apply a past plugin update) and started array same behavior can't ssh and dash stops loading. Because the disks aren't mounting I can't really see what's in the syslog file.

I have it up in maintenance mode finishing a parity check it's been up for 8 hours maybe and running fine, one disk is showing errors but not the parity. Do you mean this USB tool https://unraid.net/blog/new-usb-creator?

Not yet, was trying to exhaust options before getting too invasive because I haven't changed anything it just started doing this out of the blue.

The server seems to be working fine, until I start the array. Then I lose access to ssh(terminates my existing sessions) and nginx just starts giving me 4XX but it's still responding and the server is up.

I don't think there is a conflict now (not sure there was at any point, I do have it set to a fixed IP in unifi now). What was odd was I could access the unraid ux for a time at an IP I didn't see in unifi which was very strange. Now when unraid starts it seems like nginx is no longer loading the unraid dashboard for some reason, it's up but it doesn't load the /login and you can't get to /Main etc..

Even when I set the static ip in unifi for the host I get a 403 when I try and hit the dashboard or 404 for /login. I remember it used to be that there was an admin ip and then the main server dash ip. When the server first starts up I can access the dashboard but then it quickly goes away and I can't even ssh into the host at the IP I see on the network. I was able to ssh in to the ip even though the dashborad / nginx isn't accessible finally. I see the ip assigned on the br0 interface but not on eth0. Nothing in the logs on /var/log/nginx/error.log and nginx is running. I can see nginx listening on the ip from netstat which you'd expect given it's responding with 4XX but it's like it's not loading the unraid app or something.

yeah I definitely think the issue started after the upgrade.

I have had to reboot the server manually a couple times but then it happens again after every restart, like I can go to *.50 right now and see the Unraid dash (which doesn't show in my unifi console) but if I go to *.2 I get the nginx 403 message.

Server starts up and seems to be running fine but I can't access it on the IP registered in Unifi and I get403 and 404s when trying to access the main UX. I also don't seem to be able to ssh anymore into the host, even though ssh is enabled on port 22 in management settings. ssh -v root@[theIP] OpenSSH_9.6p1, LibreSSL 3.3.6 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files debug1: /etc/ssh/ssh_config line 54: Applying options for * debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling debug1: Connecting to [theIP] [theIP] port 22. debug1: connect to address [theIP] port 22: Connection refused ssh: connect to host [theIP] port 22: Connection refused As mentioned, I run unifi for networking and something I'm noticing is I can connect to the unraid server on an IP in the browser that doesn't show up in unifi as a client device ip anywhere (I can't SSH to that IP though either). The ip my unraid shows up as in unifi is different from the ip I can connect to the dashboard on. This started happening in the last week or so. I can see the IP address in the network settings on unraid that I'm connecting to as the one set but it's different than what I see in unifi. Not sure how to reconcile this difference or why it just started happening. I am now on Unraid 7.0.0 which is the only recent change I can think of. Attached the diagnostics also. diagnostics-20250220-0929.zip

yeah nothing new here yet unfortunately, will monitor

Here is the full log Nov 23 17:06:58 myServerName rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="19826" x-info="https://www.rsyslog.com"] start Nov 23 17:07:03 myServerName kernel: eth0: renamed from veth6293f7f Nov 23 17:07:03 myServerName kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth063b6b7: link becomes ready Nov 23 17:07:03 myServerName kernel: docker0: port 1(veth063b6b7) entered blocking state Nov 23 17:07:03 myServerName kernel: docker0: port 1(veth063b6b7) entered forwarding state Nov 23 17:07:10 myServerName rc.docker: radarr: started succesfully! Nov 23 17:07:10 myServerName kernel: docker0: port 2(veth3e07586) entered blocking state Nov 23 17:07:10 myServerName kernel: docker0: port 2(veth3e07586) entered disabled state Nov 23 17:07:10 myServerName kernel: device veth3e07586 entered promiscuous mode Nov 23 17:07:12 myServerName kernel: md: recovery thread: P corrected, sector=12679784 Nov 23 17:07:17 myServerName kernel: md: recovery thread: P corrected, sector=13714288 Nov 23 17:07:22 myServerName kernel: md: recovery thread: P corrected, sector=14577304 Nov 23 17:07:32 myServerName kernel: md: recovery thread: P corrected, sector=17106632 Nov 23 17:07:43 myServerName kernel: eth0: renamed from vethdd478f7 Nov 23 17:07:43 myServerName kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth3e07586: link becomes ready Nov 23 17:07:43 myServerName kernel: docker0: port 2(veth3e07586) entered blocking state Nov 23 17:07:43 myServerName kernel: docker0: port 2(veth3e07586) entered forwarding state Nov 23 17:07:47 myServerName rc.docker: sabnzbd: started succesfully! Nov 23 17:07:47 myServerName kernel: docker0: port 3(vethbb7ea47) entered blocking state Nov 23 17:07:47 myServerName kernel: docker0: port 3(vethbb7ea47) entered disabled state Nov 23 17:07:47 myServerName kernel: device vethbb7ea47 entered promiscuous mode Nov 23 17:08:23 myServerName kernel: md: recovery thread: P corrected, sector=27342800 Nov 23 17:08:31 myServerName kernel: eth0: renamed from vethadb961c Nov 23 17:08:31 myServerName kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethbb7ea47: link becomes ready Nov 23 17:08:31 myServerName kernel: docker0: port 3(vethbb7ea47) entered blocking state Nov 23 17:08:31 myServerName kernel: docker0: port 3(vethbb7ea47) entered forwarding state Nov 23 17:08:44 myServerName kernel: md: recovery thread: P corrected, sector=31626648 Nov 23 17:08:53 myServerName kernel: md: recovery thread: P corrected, sector=34083432 Nov 23 17:09:04 myServerName rc.docker: sonarr: started succesfully! Nov 23 17:09:44 myServerName kernel: md: recovery thread: P corrected, sector=44380288 Nov 23 17:10:02 myServerName kernel: md: recovery thread: P corrected, sector=49103216 Nov 23 17:10:47 myServerName kernel: md: recovery thread: P corrected, sector=60961112 Nov 23 17:11:32 myServerName kernel: md: recovery thread: P corrected, sector=72896048 Nov 23 17:12:21 myServerName kernel: md: recovery thread: P corrected, sector=84999720 Nov 23 17:14:28 myServerName kernel: md: recovery thread: P corrected, sector=89507024 Nov 23 17:14:48 myServerName kernel: md: recovery thread: P corrected, sector=94699576 Nov 23 17:15:00 myServerName root: Fix Common Problems Version 2024.11.12 Nov 23 17:15:01 myServerName root: Fix Common Problems: Warning: Share isos set to not use the cache, but files / folders exist on the cache drive Nov 23 17:15:01 myServerName root: Fix Common Problems: Warning: Share plex set to not use the cache, but files / folders exist on the cache drive Nov 23 17:16:11 myServerName kernel: md: recovery thread: P corrected, sector=104235408 Nov 23 17:17:54 myServerName kernel: md: recovery thread: P corrected, sector=131345416 Nov 23 17:17:59 myServerName kernel: md: recovery thread: P corrected, sector=132511616 Nov 23 17:18:15 myServerName kernel: md: recovery thread: P corrected, sector=136833872 Nov 23 17:19:04 myServerName kernel: md: recovery thread: P corrected, sector=149706960 Nov 23 17:19:10 myServerName kernel: md: recovery thread: P corrected, sector=151161104 Nov 23 17:19:29 myServerName kernel: md: recovery thread: P corrected, sector=156101576 Nov 23 17:20:00 myServerName kernel: md: recovery thread: P corrected, sector=164355280 Nov 23 17:20:59 myServerName kernel: md: recovery thread: P corrected, sector=180052032 Nov 23 17:21:01 myServerName kernel: md: recovery thread: P corrected, sector=180547568 Nov 23 17:21:12 myServerName kernel: md: recovery thread: P corrected, sector=183381768 Nov 23 17:22:33 myServerName kernel: md: recovery thread: P corrected, sector=204727864 Nov 23 17:23:40 myServerName kernel: md: recovery thread: P corrected, sector=222200256 Nov 23 17:24:21 myServerName kernel: md: recovery thread: P corrected, sector=232910848 Nov 23 17:24:45 myServerName kernel: md: recovery thread: P corrected, sector=239264280 Nov 23 17:24:57 myServerName kernel: md: recovery thread: P corrected, sector=242357656 Nov 23 17:25:08 myServerName kernel: md: recovery thread: P corrected, sector=245320368 Nov 23 17:25:26 myServerName kernel: md: recovery thread: P corrected, sector=250085848 Nov 23 17:25:27 myServerName kernel: md: recovery thread: P corrected, sector=250612048 Nov 23 17:25:32 myServerName kernel: md: recovery thread: P corrected, sector=251627096 Nov 23 17:26:25 myServerName kernel: md: recovery thread: P corrected, sector=265546632 Nov 23 17:26:36 myServerName kernel: md: recovery thread: P corrected, sector=268550400 Nov 23 17:27:02 myServerName kernel: md: recovery thread: P corrected, sector=275283880 Nov 23 17:27:18 myServerName kernel: md: recovery thread: P corrected, sector=279426672 Nov 23 17:27:29 myServerName kernel: md: recovery thread: P corrected, sector=282423296 Nov 23 17:28:03 myServerName kernel: md: recovery thread: P corrected, sector=291136248 Nov 23 17:28:20 myServerName kernel: md: recovery thread: P corrected, sector=295646088 Nov 23 17:28:22 myServerName kernel: md: recovery thread: P corrected, sector=296361320 Nov 23 17:29:30 myServerName kernel: md: recovery thread: P corrected, sector=314237400 Nov 23 17:29:39 myServerName kernel: md: recovery thread: P corrected, sector=316660504 Nov 23 17:31:32 myServerName kernel: md: recovery thread: P corrected, sector=346108648 Nov 23 17:32:17 myServerName kernel: md: recovery thread: P corrected, sector=358092032 Nov 23 17:34:11 myServerName kernel: md: recovery thread: P corrected, sector=387796592 Nov 23 17:34:43 myServerName kernel: md: recovery thread: P corrected, sector=396080000 Nov 23 17:34:57 myServerName kernel: md: recovery thread: P corrected, sector=399825072 Nov 23 17:35:06 myServerName kernel: md: recovery thread: P corrected, sector=402058576 Nov 23 17:35:15 myServerName kernel: md: recovery thread: P corrected, sector=404391440 Nov 23 17:36:06 myServerName kernel: md: recovery thread: P corrected, sector=417507656 Nov 23 17:36:27 myServerName kernel: md: recovery thread: P corrected, sector=422999592 Nov 23 17:36:37 myServerName kernel: md: recovery thread: P corrected, sector=425468064 Nov 23 17:38:31 myServerName kernel: md: recovery thread: P corrected, sector=455213128 Nov 23 17:38:41 myServerName kernel: md: recovery thread: P corrected, sector=457649208 Nov 23 17:39:27 myServerName kernel: md: recovery thread: P corrected, sector=469630544 Nov 23 17:39:56 myServerName kernel: md: recovery thread: P corrected, sector=477401856 Nov 23 17:41:01 myServerName kernel: md: recovery thread: P corrected, sector=494411032 Nov 23 17:41:51 myServerName kernel: md: recovery thread: P corrected, sector=507109376 Nov 23 17:42:47 myServerName kernel: md: recovery thread: P corrected, sector=521501920 Nov 23 17:42:48 myServerName kernel: md: recovery thread: P corrected, sector=521711576 Nov 23 17:43:12 myServerName kernel: md: recovery thread: P corrected, sector=528142136 Nov 23 17:43:53 myServerName kernel: md: recovery thread: P corrected, sector=538591120 Nov 23 17:43:54 myServerName kernel: md: recovery thread: P corrected, sector=538882184 Nov 23 17:46:27 myServerName kernel: md: recovery thread: P corrected, sector=578627096 Nov 23 17:46:38 myServerName kernel: md: recovery thread: P corrected, sector=581355496 Nov 23 17:47:23 myServerName kernel: md: recovery thread: P corrected, sector=593354592 Nov 23 17:51:49 myServerName kernel: md: recovery thread: P corrected, sector=662301352 Nov 23 17:52:48 myServerName kernel: md: recovery thread: P corrected, sector=677532368 Nov 23 17:52:49 myServerName kernel: md: recovery thread: P corrected, sector=677660712 Nov 23 17:54:12 myServerName kernel: md: recovery thread: P corrected, sector=699100896 Nov 23 17:54:19 myServerName kernel: md: recovery thread: P corrected, sector=700775216 Nov 23 17:58:45 myServerName kernel: md: recovery thread: P corrected, sector=768942424 Nov 23 18:00:11 myServerName kernel: md: recovery thread: P corrected, sector=790824928 Nov 23 18:00:13 myServerName kernel: md: recovery thread: P corrected, sector=791368064 Nov 23 18:00:39 myServerName kernel: md: recovery thread: P corrected, sector=797920960 Nov 23 18:00:41 myServerName kernel: md: recovery thread: P corrected, sector=798448704 Nov 23 18:05:18 myServerName kernel: md: recovery thread: P corrected, sector=869254136 Nov 23 18:05:56 myServerName kernel: md: recovery thread: P corrected, sector=879101576 Nov 23 18:05:57 myServerName kernel: md: recovery thread: P corrected, sector=879522816 Nov 23 18:06:25 myServerName kernel: md: recovery thread: P corrected, sector=886672120 Nov 23 18:08:24 myServerName kernel: md: recovery thread: P corrected, sector=917132872 Nov 23 18:08:25 myServerName kernel: md: recovery thread: P corrected, sector=917352056 Nov 23 18:09:59 myServerName kernel: md: recovery thread: P corrected, sector=941638560 Nov 23 18:10:28 myServerName kernel: md: recovery thread: P corrected, sector=949111848 Nov 23 18:11:40 myServerName kernel: md: recovery thread: P corrected, sector=967835472 Nov 23 18:11:57 myServerName kernel: md: recovery thread: P corrected, sector=971971848 Nov 23 18:14:11 myServerName kernel: md: recovery thread: P corrected, sector=1006107632 Nov 23 18:14:48 myServerName kernel: md: recovery thread: P corrected, sector=1015395672 Nov 23 18:16:27 myServerName kernel: md: recovery thread: P corrected, sector=1040686624 Nov 23 18:16:57 myServerName kernel: md: recovery thread: P corrected, sector=1048142864 Nov 23 18:20:07 myServerName kernel: md: recovery thread: P corrected, sector=1096467048 Nov 23 18:22:54 myServerName kernel: md: recovery thread: P corrected, sector=1138094544 Nov 23 18:24:35 myServerName kernel: md: recovery thread: P corrected, sector=1163398368 Nov 23 18:25:31 myServerName kernel: md: recovery thread: P corrected, sector=1177460256 Nov 23 18:26:42 myServerName kernel: md: recovery thread: P corrected, sector=1195255384 Nov 23 18:28:15 myServerName kernel: md: recovery thread: P corrected, sector=1218700072 Nov 23 18:31:08 myServerName kernel: md: recovery thread: stopped logging Nov 24 13:39:26 myServerName root: Delaying execution of fix common problems scan for 10 minutes Nov 24 13:39:26 myServerName unassigned.devices: Mounting 'Auto Mount' Devices... Nov 24 13:39:26 myServerName unassigned.devices: Disk with ID 'Samsung_SSD_850_EVO_250GB_S2R5NB0HC04813P (dev1)' is not set to auto mount. Nov 24 13:39:26 myServerName emhttpd: Starting services... Nov 24 13:39:26 myServerName emhttpd: shcmd (238): /etc/rc.d/rc.samba restart Nov 24 13:39:26 myServerName wsdd2[9092]: 'Terminated' signal received. Nov 24 13:39:26 myServerName nmbd[9082]: [2024/11/24 13:39:26.044670, 0] ../../source3/nmbd/nmbd.c:59(terminate) Nov 24 13:39:26 myServerName nmbd[9082]: Got SIGTERM: going down... Nov 24 13:39:26 myServerName winbindd[9097]: [2024/11/24 13:39:26.044685, 0] ../../source3/winbindd/winbindd_dual.c:1950(winbindd_sig_term_handler) Nov 24 13:39:26 myServerName winbindd[9097]: Got sig[15] terminate (is_parent=0) Nov 24 13:39:26 myServerName winbindd[9095]: [2024/11/24 13:39:26.044687, 0] ../../source3/winbindd/winbindd_dual.c:1950(winbindd_sig_term_handler) Nov 24 13:39:26 myServerName winbindd[9095]: Got sig[15] terminate (is_parent=1) Nov 24 13:39:26 myServerName wsdd2[9092]: terminating. Nov 24 13:39:26 myServerName winbindd[9304]: [2024/11/24 13:39:26.044725, 0] ../../source3/winbindd/winbindd_dual.c:1950(winbindd_sig_term_handler) Nov 24 13:39:26 myServerName winbindd[9304]: Got sig[15] terminate (is_parent=0) Nov 24 13:39:27 myServerName rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="15270" x-info="https://www.rsyslog.com"] start Nov 24 13:39:28 myServerName root: Starting Samba: /usr/sbin/smbd -D Nov 24 13:39:28 myServerName smbd[15387]: [2024/11/24 13:39:28.212764, 0] ../../source3/smbd/server.c:1741(main) Nov 24 13:39:28 myServerName smbd[15387]: smbd version 4.17.12 started. Nov 24 13:39:28 myServerName smbd[15387]: Copyright Andrew Tridgell and the Samba Team 1992-2022 Nov 24 13:39:28 myServerName root: /usr/sbin/nmbd -D Nov 24 13:39:28 myServerName nmbd[15389]: [2024/11/24 13:39:28.221576, 0] ../../source3/nmbd/nmbd.c:901(main) Nov 24 13:39:28 myServerName nmbd[15389]: nmbd version 4.17.12 started. Nov 24 13:39:28 myServerName nmbd[15389]: Copyright Andrew Tridgell and the Samba Team 1992-2022 Nov 24 13:39:28 myServerName root: /usr/sbin/wsdd2 -d -4 Nov 24 13:39:28 myServerName wsdd2[15403]: starting. Nov 24 13:39:28 myServerName root: /usr/sbin/winbindd -D Nov 24 13:39:28 myServerName winbindd[15404]: [2024/11/24 13:39:28.260129, 0] ../../source3/winbindd/winbindd.c:1440(main) Nov 24 13:39:28 myServerName winbindd[15404]: winbindd version 4.17.12 started. Nov 24 13:39:28 myServerName winbindd[15404]: Copyright Andrew Tridgell and the Samba Team 1992-2022 Nov 24 13:39:28 myServerName winbindd[15406]: [2024/11/24 13:39:28.261871, 0] ../../source3/winbindd/winbindd_cache.c:3117(initialize_winbindd_cache) Nov 24 13:39:28 myServerName winbindd[15406]: initialize_winbindd_cache: clearing cache and re-creating with version number 2 Nov 24 13:39:28 myServerName emhttpd: shcmd (242): /etc/rc.d/rc.avahidaemon restart Nov 24 13:39:28 myServerName root: Stopping Avahi mDNS/DNS-SD Daemon: stopped Nov 24 13:39:28 myServerName avahi-dnsconfd[9168]: read(): EOF Nov 24 13:39:28 myServerName root: Starting Avahi mDNS/DNS-SD Daemon: /usr/sbin/avahi-daemon -D Nov 24 13:39:28 myServerName avahi-daemon[15483]: Found user 'avahi' (UID 61) and group 'avahi' (GID 214). Nov 24 13:39:28 myServerName avahi-daemon[15483]: Successfully dropped root privileges. Nov 24 13:39:28 myServerName avahi-daemon[15483]: avahi-daemon 0.8 starting up. Nov 24 13:39:28 myServerName avahi-daemon[15483]: Successfully called chroot(). Nov 24 13:39:28 myServerName avahi-daemon[15483]: Successfully dropped remaining capabilities. Nov 24 13:39:28 myServerName avahi-daemon[15483]: Loading service file /services/sftp-ssh.service. Nov 24 13:39:28 myServerName avahi-daemon[15483]: Loading service file /services/smb.service. Nov 24 13:39:28 myServerName avahi-daemon[15483]: Loading service file /services/ssh.service. Nov 24 13:39:28 myServerName avahi-daemon[15483]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.46. Nov 24 13:39:28 myServerName avahi-daemon[15483]: New relevant interface br0.IPv4 for mDNS. Nov 24 13:39:28 myServerName avahi-daemon[15483]: Network interface enumeration completed. Nov 24 13:39:28 myServerName avahi-daemon[15483]: Registering new address record for 192.168.1.46 on br0.IPv4. Nov 24 13:39:28 myServerName emhttpd: shcmd (243): /etc/rc.d/rc.avahidnsconfd restart Nov 24 13:39:28 myServerName root: Stopping Avahi mDNS/DNS-SD DNS Server Configuration Daemon: stopped Nov 24 13:39:28 myServerName root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon: /usr/sbin/avahi-dnsconfd -D Nov 24 13:39:28 myServerName avahi-dnsconfd[15494]: Successfully connected to Avahi daemon. Nov 24 13:39:28 myServerName emhttpd: shcmd (254): /usr/local/sbin/mount_image '/mnt/user/system/docker/docker.img' /var/lib/docker 20 Nov 24 13:39:28 myServerName kernel: loop2: detected capacity change from 0 to 41943040 Nov 24 13:39:28 myServerName kernel: BTRFS: device fsid f1cce9ca-f8a7-42bd-9df5-a933743e90aa devid 1 transid 1225093 /dev/loop2 scanned by mount (15557) Nov 24 13:39:28 myServerName kernel: BTRFS info (device loop2): first mount of filesystem f1cce9ca-f8a7-42bd-9df5-a933743e90aa Nov 24 13:39:28 myServerName kernel: BTRFS info (device loop2): using crc32c (crc32c-intel) checksum algorithm Nov 24 13:39:28 myServerName kernel: BTRFS info (device loop2): using free space tree Nov 24 13:39:28 myServerName kernel: BTRFS info (device loop2): bdev /dev/loop2 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0 Nov 24 13:39:28 myServerName kernel: BTRFS info (device loop2): start tree-log replay Nov 24 13:39:28 myServerName kernel: BTRFS info (device loop2): checking UUID tree Nov 24 13:39:28 myServerName root: Resize device id 1 (/dev/loop2) from 20.00GiB to max Nov 24 13:39:28 myServerName emhttpd: shcmd (256): /etc/rc.d/rc.docker start Nov 24 13:39:28 myServerName root: starting dockerd ... Nov 24 13:39:29 myServerName avahi-daemon[15483]: Server startup complete. Host name is myServerName.local. Local service cookie is 4136015546. Nov 24 13:39:30 myServerName avahi-daemon[15483]: Service "myServerName" (/services/ssh.service) successfully established. Nov 24 13:39:30 myServerName avahi-daemon[15483]: Service "myServerName" (/services/smb.service) successfully established. Nov 24 13:39:30 myServerName avahi-daemon[15483]: Service "myServerName" (/services/sftp-ssh.service) successfully established. Nov 24 13:39:33 myServerName kernel: Bridge firewalling registered Nov 24 13:39:33 myServerName kernel: Initializing XFRM netlink socket Nov 24 13:39:41 myServerName kernel: eth0: renamed from veth9aa5ab4 Nov 24 13:39:42 myServerName emhttpd: shcmd (270): /usr/local/sbin/mount_image '/mnt/user/system/libvirt/libvirt.img' /etc/libvirt 1 Nov 24 13:39:43 myServerName kernel: loop3: detected capacity change from 0 to 2097152 Nov 24 13:39:43 myServerName kernel: BTRFS: device fsid b2fe3c72-b433-4753-b920-5e9e9d65b668 devid 1 transid 24 /dev/loop3 scanned by mount (16442) Nov 24 13:39:43 myServerName kernel: BTRFS info (device loop3): first mount of filesystem b2fe3c72-b433-4753-b920-5e9e9d65b668 Nov 24 13:39:43 myServerName kernel: BTRFS info (device loop3): using crc32c (crc32c-intel) checksum algorithm Nov 24 13:39:43 myServerName kernel: BTRFS info (device loop3): using free space tree Nov 24 13:39:44 myServerName root: Resize device id 1 (/dev/loop3) from 1.00GiB to max Nov 24 13:39:44 myServerName emhttpd: shcmd (272): /etc/rc.d/rc.libvirt start Nov 24 13:39:44 myServerName root: Starting virtlockd... Nov 24 13:39:44 myServerName root: Starting virtlogd... Nov 24 13:39:44 myServerName root: Starting libvirtd... Nov 24 13:39:44 myServerName kernel: tun: Universal TUN/TAP device driver, 1.6 Nov 24 13:39:44 myServerName kernel: mdcmd (36): check correct Nov 24 13:39:44 myServerName kernel: md: recovery thread: check P ... Nov 24 13:39:44 myServerName dnsmasq[16593]: started, version 2.89 cachesize 150 Nov 24 13:39:44 myServerName dnsmasq[16593]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile Nov 24 13:39:44 myServerName dnsmasq-dhcp[16593]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h Nov 24 13:39:44 myServerName dnsmasq-dhcp[16593]: DHCP, sockets bound exclusively to interface virbr0 Nov 24 13:39:44 myServerName dnsmasq[16593]: reading /etc/resolv.conf Nov 24 13:39:44 myServerName dnsmasq[16593]: using nameserver 192.168.1.1#53 Nov 24 13:39:44 myServerName dnsmasq[16593]: read /etc/hosts - 2 names Nov 24 13:39:44 myServerName dnsmasq[16593]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 names Nov 24 13:39:44 myServerName dnsmasq-dhcp[16593]: read /var/lib/libvirt/dnsmasq/default.hostsfile Nov 24 13:39:44 myServerName kernel: r8169 0000:03:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM Nov 24 13:39:46 myServerName kernel: r8169 0000:03:00.0 eth0: Link is Down Nov 24 13:39:46 myServerName kernel: bond0: (slave eth0): link status definitely down, disabling slave Nov 24 13:39:46 myServerName kernel: device eth0 left promiscuous mode Nov 24 13:39:46 myServerName kernel: bond0: now running without any active interface! Nov 24 13:39:46 myServerName kernel: br0: port 1(bond0) entered disabled state Nov 24 13:39:47 myServerName tips.and.tweaks: Tweaks Applied Nov 24 13:39:47 myServerName unassigned.devices: Mounting 'Auto Mount' Remote Shares... Nov 24 13:39:47 myServerName dhcpcd[1613]: br0: carrier lost Nov 24 13:40:21 myServerName kernel: md: recovery thread: P corrected, sector=7983904 Nov 24 13:40:21 myServerName rsyslogd: action 'action-2-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2102.0 try https://www.rsyslog.com/e/2359 ]

this is what I see after what seems to be the crash and then hard reboot I initiated Nov 23 17:08:31 myServerName kernel: eth0: renamed from vethadb961c Nov 23 17:08:31 myServerName kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethbb7ea47: link becomes ready Nov 23 17:08:31 myServerName kernel: docker0: port 3(vethbb7ea47) entered blocking state Nov 23 17:08:31 myServerName kernel: docker0: port 3(vethbb7ea47) entered forwarding state Nov 23 17:08:44 myServerName kernel: md: recovery thread: P corrected, sector=31626648 Nov 23 17:08:53 myServerName kernel: md: recovery thread: P corrected, sector=34083432 Nov 23 17:09:04 myServerName rc.docker: sonarr: started succesfully! Nov 23 17:09:44 myServerName kernel: md: recovery thread: P corrected, sector=44380288 Nov 23 17:10:02 myServerName kernel: md: recovery thread: P corrected, sector=49103216 Nov 23 17:10:47 myServerName kernel: md: recovery thread: P corrected, sector=60961112 Nov 23 17:11:32 myServerName kernel: md: recovery thread: P corrected, sector=72896048 Nov 23 17:12:21 myServerName kernel: md: recovery thread: P corrected, sector=84999720 Nov 23 17:14:28 myServerName kernel: md: recovery thread: P corrected, sector=89507024 Nov 23 17:14:48 myServerName kernel: md: recovery thread: P corrected, sector=94699576 Nov 23 17:15:00 myServerName root: Fix Common Problems Version 2024.11.12 Nov 23 17:15:01 myServerName root: Fix Common Problems: Warning: Share isos set to not use the cache, but files / folders exist on the cache drive Nov 23 17:15:01 myServerName root: Fix Common Problems: Warning: Share plex set to not use the cache, but files / folders exist on the cache drive Nov 23 17:16:11 myServerName kernel: md: recovery thread: P corrected, sector=104235408 Nov 23 17:17:54 myServerName kernel: md: recovery thread: P corrected, sector=131345416 Nov 23 17:17:59 myServerName kernel: md: recovery thread: P corrected, sector=132511616 Nov 23 17:18:15 myServerName kernel: md: recovery thread: P corrected, sector=136833872 Nov 23 17:19:04 myServerName kernel: md: recovery thread: P corrected, sector=149706960 Nov 23 17:19:10 myServerName kernel: md: recovery thread: P corrected, sector=151161104 Nov 23 17:19:29 myServerName kernel: md: recovery thread: P corrected, sector=156101576 Nov 23 17:20:00 myServerName kernel: md: recovery thread: P corrected, sector=164355280 Nov 23 17:20:59 myServerName kernel: md: recovery thread: P corrected, sector=180052032 Nov 23 17:21:01 myServerName kernel: md: recovery thread: P corrected, sector=180547568 Nov 23 17:21:12 myServerName kernel: md: recovery thread: P corrected, sector=183381768 Nov 23 17:22:33 myServerName kernel: md: recovery thread: P corrected, sector=204727864 Nov 23 17:23:40 myServerName kernel: md: recovery thread: P corrected, sector=222200256 Nov 23 17:24:21 myServerName kernel: md: recovery thread: P corrected, sector=232910848 Nov 23 17:24:45 myServerName kernel: md: recovery thread: P corrected, sector=239264280 Nov 23 17:24:57 myServerName kernel: md: recovery thread: P corrected, sector=242357656 Nov 23 17:25:08 myServerName kernel: md: recovery thread: P corrected, sector=245320368 Nov 23 17:25:26 myServerName kernel: md: recovery thread: P corrected, sector=250085848 Nov 23 17:25:27 myServerName kernel: md: recovery thread: P corrected, sector=250612048 Nov 23 17:25:32 myServerName kernel: md: recovery thread: P corrected, sector=251627096 Nov 23 17:26:25 myServerName kernel: md: recovery thread: P corrected, sector=265546632 Nov 23 17:26:36 myServerName kernel: md: recovery thread: P corrected, sector=268550400 Nov 23 17:27:02 myServerName kernel: md: recovery thread: P corrected, sector=275283880 Nov 23 17:27:18 myServerName kernel: md: recovery thread: P corrected, sector=279426672 Nov 23 17:27:29 myServerName kernel: md: recovery thread: P corrected, sector=282423296 Nov 23 17:28:03 myServerName kernel: md: recovery thread: P corrected, sector=291136248 Nov 23 17:28:20 myServerName kernel: md: recovery thread: P corrected, sector=295646088 Nov 23 17:28:22 myServerName kernel: md: recovery thread: P corrected, sector=296361320 Nov 23 17:29:30 myServerName kernel: md: recovery thread: P corrected, sector=314237400 Nov 23 17:29:39 myServerName kernel: md: recovery thread: P corrected, sector=316660504 Nov 23 17:31:32 myServerName kernel: md: recovery thread: P corrected, sector=346108648 Nov 23 17:32:17 myServerName kernel: md: recovery thread: P corrected, sector=358092032 Nov 23 17:34:11 myServerName kernel: md: recovery thread: P corrected, sector=387796592 Nov 23 17:34:43 myServerName kernel: md: recovery thread: P corrected, sector=396080000 Nov 23 17:34:57 myServerName kernel: md: recovery thread: P corrected, sector=399825072 Nov 23 17:35:06 myServerName kernel: md: recovery thread: P corrected, sector=402058576 Nov 23 17:35:15 myServerName kernel: md: recovery thread: P corrected, sector=404391440 Nov 23 17:36:06 myServerName kernel: md: recovery thread: P corrected, sector=417507656 Nov 23 17:36:27 myServerName kernel: md: recovery thread: P corrected, sector=422999592 Nov 23 17:36:37 myServerName kernel: md: recovery thread: P corrected, sector=425468064 Nov 23 17:38:31 myServerName kernel: md: recovery thread: P corrected, sector=455213128 Nov 23 17:38:41 myServerName kernel: md: recovery thread: P corrected, sector=457649208 Nov 23 17:39:27 myServerName kernel: md: recovery thread: P corrected, sector=469630544 Nov 23 17:39:56 myServerName kernel: md: recovery thread: P corrected, sector=477401856 Nov 23 17:41:01 myServerName kernel: md: recovery thread: P corrected, sector=494411032 Nov 23 17:41:51 myServerName kernel: md: recovery thread: P corrected, sector=507109376 Nov 23 17:42:47 myServerName kernel: md: recovery thread: P corrected, sector=521501920 Nov 23 17:42:48 myServerName kernel: md: recovery thread: P corrected, sector=521711576 Nov 23 17:43:12 myServerName kernel: md: recovery thread: P corrected, sector=528142136 Nov 23 17:43:53 myServerName kernel: md: recovery thread: P corrected, sector=538591120 Nov 23 17:43:54 myServerName kernel: md: recovery thread: P corrected, sector=538882184 Nov 23 17:46:27 myServerName kernel: md: recovery thread: P corrected, sector=578627096 Nov 23 17:46:38 myServerName kernel: md: recovery thread: P corrected, sector=581355496 Nov 23 17:47:23 myServerName kernel: md: recovery thread: P corrected, sector=593354592 Nov 23 17:51:49 myServerName kernel: md: recovery thread: P corrected, sector=662301352 Nov 23 17:52:48 myServerName kernel: md: recovery thread: P corrected, sector=677532368 Nov 23 17:52:49 myServerName kernel: md: recovery thread: P corrected, sector=677660712 Nov 23 17:54:12 myServerName kernel: md: recovery thread: P corrected, sector=699100896 Nov 23 17:54:19 myServerName kernel: md: recovery thread: P corrected, sector=700775216 Nov 23 17:58:45 myServerName kernel: md: recovery thread: P corrected, sector=768942424 Nov 23 18:00:11 myServerName kernel: md: recovery thread: P corrected, sector=790824928 Nov 23 18:00:13 myServerName kernel: md: recovery thread: P corrected, sector=791368064 Nov 23 18:00:39 myServerName kernel: md: recovery thread: P corrected, sector=797920960 Nov 23 18:00:41 myServerName kernel: md: recovery thread: P corrected, sector=798448704 Nov 23 18:05:18 myServerName kernel: md: recovery thread: P corrected, sector=869254136 Nov 23 18:05:56 myServerName kernel: md: recovery thread: P corrected, sector=879101576 Nov 23 18:05:57 myServerName kernel: md: recovery thread: P corrected, sector=879522816 Nov 23 18:06:25 myServerName kernel: md: recovery thread: P corrected, sector=886672120 Nov 23 18:08:24 myServerName kernel: md: recovery thread: P corrected, sector=917132872 Nov 23 18:08:25 myServerName kernel: md: recovery thread: P corrected, sector=917352056 Nov 23 18:09:59 myServerName kernel: md: recovery thread: P corrected, sector=941638560 Nov 23 18:10:28 myServerName kernel: md: recovery thread: P corrected, sector=949111848 Nov 23 18:11:40 myServerName kernel: md: recovery thread: P corrected, sector=967835472 Nov 23 18:11:57 myServerName kernel: md: recovery thread: P corrected, sector=971971848 Nov 23 18:14:11 myServerName kernel: md: recovery thread: P corrected, sector=1006107632 Nov 23 18:14:48 myServerName kernel: md: recovery thread: P corrected, sector=1015395672 Nov 23 18:16:27 myServerName kernel: md: recovery thread: P corrected, sector=1040686624 Nov 23 18:16:57 myServerName kernel: md: recovery thread: P corrected, sector=1048142864 Nov 23 18:20:07 myServerName kernel: md: recovery thread: P corrected, sector=1096467048 Nov 23 18:22:54 myServerName kernel: md: recovery thread: P corrected, sector=1138094544 Nov 23 18:24:35 myServerName kernel: md: recovery thread: P corrected, sector=1163398368 Nov 23 18:25:31 myServerName kernel: md: recovery thread: P corrected, sector=1177460256 Nov 23 18:26:42 myServerName kernel: md: recovery thread: P corrected, sector=1195255384 Nov 23 18:28:15 myServerName kernel: md: recovery thread: P corrected, sector=1218700072 Nov 23 18:31:08 myServerName kernel: md: recovery thread: stopped logging

ah got it, I thought it would just default that or not let me set it if it couldn't figure it out I wondered why I wasn't seeing files accumulate

I did have another crash but nothing in my Syslog folder in terms of files when I browse their from the UX. Here is a screenshot of the settings I had on.

no crashes yet, will post once I do

Alright, I set that up I'm worried the parity is going bad or something but we will see soon enough.

I have been having been having a good bit of instability with my build where it becomes unresponsive and I can't access the site. Then I have to hard reboot it and it goes into a parity check cycle. This is happening a couple times a week lately. I have uploaded diagnostics. diagnostics-20241019-1140.zip

Yeah I don't know why though, I plugged in the Asmedia controller and made sure it was seeded properly but then it seems to not work/detect the attached drives or card. I swapped the Marvell back in and the drives come back fine.

I swapped my old marvell controller for this one from Amazon, https://www.amazon.com/gp/product/B08LW3XXYG. And my drives just disappear and don't show up at all attached to the card. I attached my diags but I thought I should be able just to swap the card for a newer one without any big issues. diagnostics-20230719-1951.zip

I restarted the server which fixed things but why does one browser on a local computer take down the web UI? That seems really odd to me.