Astatine

Understood. I'll go through the release notes to understand the new way to do bridging. Anyways, what should I do with the potentially corrupt config? My server renamed itself to 'Tower'. ident.cfg file lists name as 'Tower'. I don't know what else might have been reset back to default. Do I need to start with 'New Config'?

I previously had issues with docker containers, thread linked. Which was solved by switching to macvlan. If I go back to that, can you suggest how to avoid the DNS issue again? I'll try switching back to ipvlan this evening and see if it makes things better

So, I was moving houses and couldn't pay attention to my UNRAID server for quite some time. I have since replaced a corrupt USB drive. Transferred my key to a new USB. It was working properly for some time but soon after that I started noticing that the server would "freeze" as in the docker services would be running but a couldn't access server using the IP. I also noticed that during boot there are these number list (my guess memory block list) which reads so: I don't understand what this is. Then the situation worsened. Now, docker containers would just randomly stop working and when tried to restart them, I would receive popup either saying "403" or "Execution error". I then either had to restart the docker service or the whole server to be able to get them to work. My guess was that the docker file is corrupted. But I couldn't still act to fix that due to life. Then the whole server started freezing. I couldn't access it over the IP, same for docker containers until I restart the machine which resulted in a ton of unclean shutdowns. And as of yesterday, after restart, the docker containers are only working for 5-10 minutes and my unraid machine name went back to "Tower" which according to this could be config issue: Server name changed from "N2" to "Tower" - General Support - Unraid Also, I am no longer able to access the server over https://[IP] but http://[IP] is showing the login screen but after entering the credentials, it doesn't take me in. Just keeps redirecting to login screen. I convinced that something is seriously off in the /config in the USB. Can someone help me track down the issue and fix it? or is it better to start from scratch? If so, when I do 'New Config' and assign the devices to their current purpose, will my data be retained? both array and cache? I understand that new config will definitely rebuild the parity. I try to somehow get the diag. report from the server directly and post it here soon Here are the diagnostics: tower-diagnostics-20240119-1839.zip Also, when I clicked 'Download' on the diagnostics page, I saw the following error on the server cli screen: Please help. It is getting very frustrating to deal with!!!!

Ah, I see. I just restarted in Safe Mode without Maintenance and can see the disks. Guess I turned on Maintenance Mode earlier. I didn't find something on Google hence posted. Sorry for the inconvenience.

Hi everyone, I am running unRAID 6.12.6 and after a reboot just now, none of the drives are showing up in /mnt I can see the drive in 'Main' tab and cannot even see the "drive explorer" button for the drives. (screenshot of Main tab) But I cannot see any shares or disks mounts in /mnt folder Please help me figure this out as to why I cannot see the none of the disk, cache or otherwise. The SMART report in the report is looking good to me but maybe I am wrong. The diagnostics report is attached to the post: astatine-diagnostics-20231216-2241.zip Thank you in advance!

Just had a weird this happen to me. I pulled up the UNRAID web UI, everything working as usual. I go Apps tab and the page is upside down. The banner/header was still in the right orientation. I switch between tabs, no effect. I restart the browser and go back to Apps tab and I see a popup asking me 'Yes' or 'No' about continuing the International Bat Appreciation Day celebration. The popup dialog had a link to this webpage: https://nationaltoday.com/international-bat-appreciation-day/ Has anyone else seen this?

Well look at that. Changing 'ipvlan' to 'macvlan' to fixed the issue. I kept all the other settings as is. Now, I am more curious as to why ipvlan had that issue and it didn't occur for the first few minutes after reboot.

@JorgeB So, I did what you asked and turns out the test unRAID flash drive has 0 issues. And after going through what @autumnwalker mentioned above, I feel like it's a known issue with how docker handles networking and hasn't been fixed yet. I'll test this theory before anything else.

@autumnwalker Yes, I am using ipvlan + host access to custom networks because I want the prowlarr, jackett containers on Host IP to communicate with some containers that are on a different IP setup using br0 interface. I'll turn off the "host access to custom networks" and see if the issue gets fixed like it did for the folks you mentioned

Thanks. I'll get back to you once I've tried it.

Well, with all due respect, I find it hard to believe that it is not an unRAID issue. I booted the server to a live ubuntu USB and left it to ping google.com, cloudflare.com & unraid.net for more than a day and the packet loss are as follows: 0% for google.com, 0.00383547% packet loss for unraid.net & 0.00153467% packet loss for cloudflare.com. So, I believe this rules out the possibility of a hardware issue. - Not a router issues as all my other devices are working just fine connecting to the outside world - Not a switch issue as all the other devices connected to the switch are working fine + unRAID server also get connection for 10-15 minutes after reboot and then loses DNS - Not a hardware issue as booting into live ubuntu USB doesn't seem to have the same DNS resolution issue as the unRAID server With this new information on hand, I can confidently say that it is an unRAID issue, whether it originates from the OS or a corrupted config file, that's a different story. ping_cloudflare.txt ping_google.txt ping_unraid.txt

I am open to setting up everything from the scratch. How can I have a fresh start without using the limited USB Key resets? I believe all the parity data, appdata, etc. will just remain the same in the new install so long as I assign the correct drive back to the same purpose. As for docker container install, I am willing to do it again and point the new containers to old appdata to bring server back to my latest state. Is there a way to accomplish the above?

Yeah, totally agreed. Time sync issue seems to have occurred due to loss of connection and not the other way around. However, I there something else that comes to mind in how to diagnose the real issue? I'm going to try booting into a live ubuntu install later in the evening and observe if something similar happens in that too. In the meantime, I was also wondering if there is way to do a fresh install of unRAID while keeping my config and settings intact. That way, if there is a corrupt file somewhere, it would be fixed. Thoughts?

Great idea. Gonna do this ASAP. Thanks!!!

So, I was looking online and found that sometimes the 'Clock Unsync' issue is caused because the BIOS time is incorrect. So, I checked that and lo & behold, the time is correct. As expected the time is in UTC and it correct. Which means we can rule out a faulty CMOS battery, right @MAM59? Anyways, good thing after my recent reboot, I am no longer seeing any clock out of sync errors. However, internet connection remains

@JorgeBOkay, so waited about an hour after booting into safe mode. The server had lost connection. I guess we can rule out a bad plugin from the things causing the issue @MAM59I rebooted and used the following commands to resync ntp /etc/rc.d/rc.ntpd stop ntpdate time.cloudflare.com /etc/rc.d/rc.ntpd restart Right after restarting the service. I checked the logs and found this Mar 14 16:33:36 astatine ntpd[1153]: ntpd exiting on signal 1 (Hangup) Mar 14 16:33:36 astatine ntpd[1153]: 127.127.1.0 local addr 127.0.0.1 -> <null> Mar 14 16:33:36 astatine ntpd[1153]: 216.239.35.0 local addr 192.168.1.4 -> <null> Mar 14 16:33:36 astatine ntpd[1153]: 216.239.35.4 local addr 192.168.1.4 -> <null> Mar 14 16:33:36 astatine ntpd[1153]: 216.239.35.8 local addr 192.168.1.4 -> <null> Mar 14 16:33:36 astatine ntpd[1153]: 216.239.35.12 local addr 192.168.1.4 -> <null> Mar 14 16:35:02 astatine ntpd[18956]: ntpd [email protected] Fri Jun 3 04:17:10 UTC 2022 (1): Starting Mar 14 16:35:02 astatine ntpd[18956]: Command line: /usr/sbin/ntpd -g -u ntp:ntp Mar 14 16:35:02 astatine ntpd[18956]: ---------------------------------------------------- Mar 14 16:35:02 astatine ntpd[18956]: ntp-4 is maintained by Network Time Foundation, Mar 14 16:35:02 astatine ntpd[18956]: Inc. (NTF), a non-profit 501(c)(3) public-benefit Mar 14 16:35:02 astatine ntpd[18956]: corporation. Support and training for ntp-4 are Mar 14 16:35:02 astatine ntpd[18956]: available at https://www.nwtime.org/support Mar 14 16:35:02 astatine ntpd[18956]: ---------------------------------------------------- Mar 14 16:35:02 astatine ntpd[18960]: proto: precision = 0.034 usec (-25) Mar 14 16:35:02 astatine ntpd[18960]: basedate set to 2022-05-22 Mar 14 16:35:02 astatine ntpd[18960]: gps base set to 2022-05-22 (week 2211) Mar 14 16:35:02 astatine ntpd[18960]: Listen normally on 0 lo 127.0.0.1:123 Mar 14 16:35:02 astatine ntpd[18960]: Listen normally on 1 br0 192.168.1.4:123 Mar 14 16:35:02 astatine ntpd[18960]: Listen normally on 2 lo [::1]:123 Mar 14 16:35:02 astatine ntpd[18960]: Listening on routing socket on fd #19 for interface updates Mar 14 16:35:02 astatine ntpd[18960]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Mar 14 16:35:02 astatine ntpd[18960]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

Okay. I'm checking what JorgeB suggested. Booted in safe mode. I'll observe the server for a while in safe mode and after ntpdate. Just bear with my stupid questions. I just want to understand as much as I can in case something like this happens in the future.

I tried this. I believe the ntp errors are coming because the npt daemon isn't able to connect with remote "clock" due to DNS issue

@JorgeB@itimpi So, I gave up on the server last night and left it on its own. Turns out a couple hours after the network reset yesterday, the server behavior changed. Now the server is connecting on and off. And I am getting new errors in the log(s). I have attached the latest diagnostics to this post. Here's a snippet of the new error(s) that I am seeing. Mar 13 11:52:22 astatine avahi-daemon[23598]: Joining mDNS multicast group on interface vethf5a568d.IPv6 with address fe80::c86c:29ff:fead:e306. Mar 13 11:52:22 astatine avahi-daemon[23598]: New relevant interface vethf5a568d.IPv6 for mDNS. Mar 13 11:52:22 astatine avahi-daemon[23598]: Registering new address record for fe80::c86c:29ff:fead:e306 on vethf5a568d.*. Mar 13 11:52:22 astatine avahi-daemon[23598]: Joining mDNS multicast group on interface veth25e0c9f.IPv6 with address fe80::44e7:81ff:fe1d:5a72. Mar 13 11:52:22 astatine avahi-daemon[23598]: New relevant interface veth25e0c9f.IPv6 for mDNS. Mar 13 11:52:22 astatine avahi-daemon[23598]: Registering new address record for fe80::44e7:81ff:fe1d:5a72 on veth25e0c9f.*. Mar 13 11:52:23 astatine avahi-daemon[23598]: Joining mDNS multicast group on interface veth21f1006.IPv6 with address fe80::307a:a5ff:fe6a:307e. Mar 13 11:52:23 astatine avahi-daemon[23598]: New relevant interface veth21f1006.IPv6 for mDNS. Mar 13 11:52:23 astatine avahi-daemon[23598]: Registering new address record for fe80::307a:a5ff:fe6a:307e on veth21f1006.*. Mar 13 11:52:23 astatine avahi-daemon[23598]: Joining mDNS multicast group on interface veth3e1bea2.IPv6 with address fe80::409b:19ff:febd:db3e. Mar 13 11:52:23 astatine avahi-daemon[23598]: New relevant interface veth3e1bea2.IPv6 for mDNS. Mar 13 11:52:23 astatine avahi-daemon[23598]: Registering new address record for fe80::409b:19ff:febd:db3e on veth3e1bea2.*. Mar 13 17:25:47 astatine nginx: 2023/03/13 17:25:47 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 13 17:25:47 astatine nginx: 2023/03/13 17:25:47 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 13 17:25:47 astatine nginx: 2023/03/13 17:25:47 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 13 17:42:32 astatine ntpd[7970]: no peer for too long, server running free now Mar 13 18:17:31 astatine ntpd[7970]: no peer for too long, server running free now Mar 13 18:24:29 astatine webGUI: Successful login user root from <tailscale ip of my phone> Checkout the log at timestamp: Mar 13 20:07:29 Mar 13 18:27:07 astatine avahi-daemon[23598]: Joining mDNS multicast group on interface veth641d21e.IPv6 with address fe80::78a8:91ff:fee9:b4be. Mar 13 18:27:07 astatine avahi-daemon[23598]: New relevant interface veth641d21e.IPv6 for mDNS. Mar 13 18:27:07 astatine avahi-daemon[23598]: Registering new address record for fe80::78a8:91ff:fee9:b4be on veth641d21e.*. Mar 13 20:07:29 astatine ntpd[7970]: receive: Unexpected origin timestamp 0xe7ba3941.9078c3b0 does not match aorg 0000000000.00000000 from [email protected] xmt 0xe7ba3940.e57b3745 Mar 14 00:59:48 astatine nginx: 2023/03/14 00:59:48 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 00:59:48 astatine nginx: 2023/03/14 00:59:48 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 00:59:48 astatine nginx: 2023/03/14 00:59:48 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 02:00:01 astatine root: mover: started Mar 14 02:00:03 astatine root: mover: finished Mar 14 02:22:58 astatine nginx: 2023/03/14 02:22:58 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 03:53:35 astatine nginx: 2023/03/14 03:53:35 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 03:53:35 astatine nginx: 2023/03/14 03:53:35 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 03:53:35 astatine nginx: 2023/03/14 03:53:35 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 04:23:08 astatine ntpd[7970]: no peer for too long, server running free now Mar 14 05:29:33 astatine nginx: 2023/03/14 05:29:33 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 05:29:33 astatine nginx: 2023/03/14 05:29:33 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 05:29:33 astatine nginx: 2023/03/14 05:29:33 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 06:18:35 astatine nginx: 2023/03/14 06:18:35 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 07:59:39 astatine ntpd[7970]: no peer for too long, server running free now Mar 14 09:02:32 astatine ntpd[7970]: no peer for too long, server running free now Mar 14 09:31:20 astatine ntpd[7970]: no peer for too long, server running free now Mar 14 10:23:03 astatine nginx: 2023/03/14 10:23:03 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 10:23:03 astatine nginx: 2023/03/14 10:23:03 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 10:23:03 astatine nginx: 2023/03/14 10:23:03 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 10:23:03 astatine nginx: 2023/03/14 10:23:03 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 10:23:03 astatine nginx: 2023/03/14 10:23:03 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 10:23:03 astatine nginx: 2023/03/14 10:23:03 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 10:23:04 astatine nginx: 2023/03/14 10:23:04 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 10:23:04 astatine nginx: 2023/03/14 10:23:04 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 10:23:04 astatine nginx: 2023/03/14 10:23:04 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 10:23:05 astatine nginx: 2023/03/14 10:23:05 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 10:23:06 astatine nginx: 2023/03/14 10:23:06 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen. Mar 14 10:23:07 astatine nginx: 2023/03/14 10:23:07 [error] 3949#3949: nchan: A message from the past has just been published. Unless the system time has been adjusted, this should never happen.

I am not using a custom router/modem. I have a Bell connection and use the router/modem provided by them. It's a Bell Home Hub 4000

v6.11.5

Already done that. No luck. It works fine for 10-15 minutes after saving the changes and then back to square one. No connection. Pings failing.

@JorgeB Here you go. astatine-diagnostics-20230313-1304.zip

I perform this in the evening. However, I just now noticed a strange thing. So, as of now I am unable to see CA tab, no docker container is able to connect to the internet, pings are failing. However, the network panel on the dashboard is show significant network activity. I saw the outbound traffic going upward to about 10Mbps as well. What can explain this?

@trurl @JorgeB guys, a little help here! Please