Chunks

I'm trying to figure out why my Unraid machine (NUT 2.8.1, APC ups) stays online during a self test, but my pfSense router (NUT 2.8.2 I think) running as "slave" is shutting itself off. I don't know if the problem is Unraids side, or pfSense's side. The Unraid log (master) shows the following: Dec 19 18:05:56 ChunksUnraid upsmon[11191]: UPS [email protected]: administratively OFF or asleep Dec 19 18:06:05 ChunksUnraid usbhid-ups[11164]: ups_status_set: seems that UPS [chunksups] is in OL+DISCHRG state now. Is it calibrating (perhaps you want to set 'onlinedischarge_calibration' option)? Note that some UPS models (e.g. CyberPower UT series) emit OL+DISCHRG when in fact offline/on-battery (perhaps you want to set 'onlinedischarge' option). Dec 19 18:06:06 ChunksUnraid upsmon[11191]: UPS [email protected]: no longer administratively OFF or asleep Syslog for my pfSense machine (slave) shows: (reverse order, oldest bottom) 2023-12-19 18:06:05 Notification (5) SHUTDOWN power-down by root: 2023-12-19 18:06:02 Error (3) PHP-CGI notify_monitor.php: Message sent to <ME> OK 2023-12-19 18:06:00 Notification (5) UPSMON Auto logout and shutdown proceeding 2023-12-19 18:06:00 Critical (2) UPSMON Executing automatic power-fail shutdown 2023-12-19 18:06:00 Notification (5) UPSMON UPS [email protected].<ME>: administratively OFF or asleep Specifically, I don't know what to do about this line here: How do I set this "onlinedischarge_calibration" option? I looked into the config area of NUT on Unraid, but honestly, I'm a bit uncertain how to set it correctly. Is it in "/etc/nut/upsmon.conf" at the bottom of the NUT page? Any advice?

I tested it manually, and I definitely did get an error this time. I still get the "The backup was successful and took 0h, 0m!" message, but this time it was proceeded by an error message. So I really don't know what happened last time. Either the message got eaten somehow, or the conditions were different. Sorry for reporting so quickly.

Not a question or a complaint or anything, but I recently added a new "unassigned devices" partition and set it up to be used with Appdata Backup. Tested it out, took almost an hour, worked fine. I had to reboot the server yesterday, and didn't notice I forgot to turn on "auto-mount" for my AppdataBackup partition/drive. So when AppdataBackup ran at it's scheduled time, it didn't do anything. Except that I got a "Success" notification sent to me - Backup done [0h, 0m]! Seemed weird, and then I figured out what happened, but perhaps the tool could confirm the destination path exists?

Indeed. device.model: Back-UPS RS 900G Never had issues with "old Nut" but I guess that's because it was using a (much?) older back end.

Thank you for the recent updates! I've never had issues with my UPS, or energy provider, but twice now my Unraid machine turned off, and it took down (gracefully) my router as well which is a "slave" via NUT. The first time it did it, I was in another country, so that was frustrating. Luckily I happened to setup remote syslog yesterday, and NUT just did it again. I captured: UPS [email protected]: administratively OFF or asleep I googled that error and the first link was this thread. I was sitting about 2 meters from the UPS and never heard an alarm or anything, but my battery wasn't full so it had definitely been used. Super weird. I didn't even know it did a self test Anyway, I have now switched to stable (2.8.0), rebooted, and will hope for the best!

I had the same issue where pressing the "move" button didn't do anything. If you go into the "Scheduler" page, under Settings, you can turn on "Mover - logging". When i did that, and manually ran the mover by clicking the button, the system log clearly showed a bunch of file-not-found errors for a .cfg file. I'm afraid I didn't save the log, but since it was related to this plugin i just removed the plugin and then Mover started working again. This was on 6.11.5 but now I'm running 6.12.4 (I upgraded just after removing this plugin, I think anyway.... it was a long night).

Can I ask for a little clarity on this statement? Is it recommended to revert from using 2 nic's to 1? Or just, running only 1 is an option now?

When moving Dockers from a single interface (eth0) to a new dedicated one (eth1).... I had no problems when the dockers were swapped from br0 to eth1 networks. But I have a whole bunch of dockers using just "bridge". These get the IP address of the host system, the main unraid IP (eth0). For example: Is the fix to make all of these eth1 as well? If so, what IP do I use? Can I create a single new address that they all can share, or is this the whole point of removing bridging? Or did I miss something/mess something up?

I have a stupid, somewhat general question. I've always kept my dockers on "Latest", but if I switch to use specific versions (I have nextcloud at 27 now)..... Is there a "best practice" to get notifications for dockers I have that DO have updates, when they get them? Or do I just randomly check them all the time?

I had the permissions problem with Grafana, and I fixed it by going to the /mnt/user/appdata folder and running: chown nobody:users grafana after that, the image started right up. (this was an existing install that stopped working)

Something to add, as I'm having similar problems - I noticed that even though my server and docker config are both set to "IPv4 only" I had some IPv6 routes in my route table (settings --> network settings --> bottom of the page) Turns out one of the dockers I recently installed is creating an IPv6 interface regardless of setting. Annoyingly, it's actually rather difficult to forcibly remove. I was going to make sure it was still gone just now and it's back, so yea, worth double checking IPv6 is ACTUALLY off.

My system is a 5950x Ryzen, and my only NIC is an Intel I211 gigabit I have a dual port Intel X550 PCIe NIC coming this week, just to try to offload all macvlan stuff to a new interface.

Oof yea. same problem here. I rolled back from 6.12.0 (live) and now only a couple of dockers work - and googling my error sent me to your thread Thanks for updating on a work around at least. Not sure what I will do at this point, reinstall everything, or go to 6.12.1 and hope for the best. Small edit to add: looks like it works fine again if you re-update. I went to 6.12.1 from 6.11.5 directly, rather than reinstall my docker images, and they all start up again.

I'm trying to learn about this problem as well. I've been using macvlan without problems for a couple years at this point, and then yesterday morning (3 days after updating to 6.12.0) I had my first system instability/crash, requiring a hard reboot. After I came back up, I had warnings about "macvlan traces found" I've already ordered a second NIC, as I do a ton of VLAN stuff with both Docker and VM's on different vlans and really want to keep using MACVLAN. But now I'm concerned that this won't actually end up helping. Is this an Unraid thing? A docker thing? Can I investigate anything to help solve it if I crash again?

I just found the problem. Chrome had bad data saved (and I guess has had it for years at this point.) Just to share, in case it's helpful: After checking the system settings as you suggested and finding no Swedish, I decided to rule out the browser itself. I tried Firefox. It worked fine in English. Then to sanity check, I tried Chrome Incognito - also worked fine in English. I cleared cookies, but it didn't help. Finally, I started digging into DevTools in Chrome. I found the place where VNC looks up the available languages. It's here: <server>/vnc/dist/main.bundle.js So I stuck a "Watch" on that variable. Even tho my Chrome installation only showed 1 "Swedish" installed, and it was set to the Lowest Priority, the "Watch" showed a second one, near the top. I guess VNC doesn't have a distinct en-GB language, so it took "sv-SE"? Anyway, long story short, completely removing Swedish from Chrome settings got rid of it, and now adding it again correctly shows it at the bottom of the list. And VNC works properly now. Sorry for wasting your time, but thanks for the inspiration to track this down.