-
Unable to ping server although it has IP
That did not work. The server is reporting the IP address that I assigned to it, and I can see the client is assigned an IP address in the Unifi OS UI. But, when I try to access Unraid from my workstation, I get a "ERR_NETWORK_ACCESS_DENIED" error. I am the admin on my home network and I have not introduced any new firewall rules in the time this issue started.
-
Unable to ping server although it has IP
Thank you for the suggestion. I replaced the battery but can still not access the server. I added the removed network config back to the boot USB as well, and now the server is not getting an IP.
-
Unable to ping server although it has IP
Overnight, my Unraid server appears to have run into a fatal error. I attached a screenshot. I find it strange that the error reports a time of February 1st, as I have been using the server through the 11th without issue. Here are some issues now Cannot access GUI on local network I can boot into GUI mode on the Unraid machine, more on this later Cannot ping the machine SMB is accessible from one VLAN but not another (both cannot access the GUI) Reconfigure network via UDM-SE such that Unraid hosted PiHoles no longer provide DNS I've been trying to get Unraid back up throughout the day, and I have done the following Ensure server does get an IP Reset IP lease for Unraid server Change IP address for Unraid server Stop all docker containers; disable docker I had Plex running, and I had read of users claiming Plex crashes caused similar issues Stop all VMs I had four PiHole VMs serving DNS for different VLANs Remove network config file The issue persists and I'm running out of ideas. I hope someone more familiar with debugging the diagnostic logs can help me determine if I need to replace hardware. I'm running memtest now. tower-diagnostics-20230213-1754.zip
-
Mover Tuning; not moving from cache based on capacity during parity
It seems I misunderstood how the mover tuner plugin worked. I thought the % fill moving condition fired independent of the schedule (ie: I could configure mover to clear the cache whenever it reached x capacity). I had calculated my average network throughput, and the 70% figure I landed on was more than enough. That is... assuming moves off cache started at a certain capacity. Which they didn't. Someone on Reddit replied to my cross-post there and answered my question: "The Mover Tuning plugin doesn't automatically run the mover when one of the conditions is met. The mover still just runs on the schedule you set." Thanks, first time posting here and I was unaware of that feature. I'll move the discussion there to confirm what I heard on reddit. Edit: Someone else had the same misunderstanding as me, and the explanation from Reddit was confirmed in the plugin thread: Guess I'll either setup the tuner to run on a faster schedule or write a bash script of my own to move at a certain filled %.
-
cities started following Mover Tuning; not moving from cache based on capacity during parity
-
Mover Tuning; not moving from cache based on capacity during parity
Had a power outage yesterday and needed to perform a 16 Tb parity rebuild (1-1.5 days). I'm still actively using my NAS, and yesterday I filled up the cache (240 Gb) twice. The first time, I was at the computer and kicked off a force move. The second time, I was sleeping, and when the cache filled up, my VMs stopped along with all file transfers (parity rebuild is still going). I know the mover (by default) does not run concurrently with a parity build. This can be configured with the "Let scheduled mover run during a parity check / rebuild" setting in Mover Tuner. Mover settings: schedule: weekly day of week: sunday day of month: N/A Time of day: 03:40 Mover logging: Enabled Mover tuning w age: All "No" "0" or "Normal" (default settings) unless otherwise specified Let scheduled mover run during a parity check / rebuild: Yes Move All from Cache-Yes shares when disk is above a certain percentage: Yes Move All from Cache-yes shares pool percentage: 70% I also checked my `/var/log/syslog`, but the only lines related to the mover were during install (ie: when searching "mover" I didn't see any lines about failed moves, which I would have expected if a capacity move attempted -- and failed -- to start). Is this a bug? Perhaps there is a missing "Let capacity mover run during a parity check / rebuild" setting. Or, do I need to do something else to ensure my cache is cleared in time to avoid it filling up?
cities
Members
-
Joined
-
Last visited