Rusty6285

Thanks for following up @ich777, yes everything is fine after a complete reinstall/deleting appdata. I did not have to clear browser cache for things to start working again - the total wipe of appdata restored functionality. By unresponsive, what I mean is I saw the same behaviour as posted earlier - the following would be displayed in the log (briefly) before it would go into a reset loop. I am running Unraid Version: 6.12.4 and I updated the luckybackup docker manually this morning - which immediately made it unusable. I was upto date on the prior version, if that helps debugging.

I'm having this same issue where luckybackup is unresponsive after last update. Same log errors as @dataslayerposted. I don't think I have a recent backup of my profiles... is there a way for me to roll back to the prior version so I can save my profiles, before removing/cleaning my config? Edit - By copying out the contents of my 'profiles' folder inside the appdata, then removing both the image and the appdata folder for a reinstall, luckybackup is now working again on a fresh install... Edit 2 - placing the saved profile files back in the new appdata seems to have restored my profiles, however they all are requiring a manual fix to the path, since it's doubled up on 'user/user' where it should only be once... Edit 3 - I seem to have lost the ability to map to remote shares? they are correctly mounted but the path /remotes/ is completely absent in the interface as of this last update. Edit 4 - I found the solution to my profile issues in edit 2 & 3 - seems in my prior install I had 'Container Path: /mnt/user' mapped to just '/mnt/' instead of '/mnt/user' to allow me access to remote shares. Mapping it back to '/mnt/' solved the double user issue, and allowed me to access remotes again.

Thanks for the suggestions @Rysz, I tried a variety of settings there and a different USB socket, but no joy - I did however confirm that the "nut_libusb_get_string: Input/Output Error" error appears at whatever frequency the polling rate is set to. For next steps, I will try a PCIe USB card to see if the controller on my motherboard is possibly at fault, and I can also try using my 2nd unraid server as the master. As a last option, I can try making my TrueNAS scale server the master, however I'm not sure if that can act as a NUT master. Will report back with any progress made, thanks again

hey folks, really appreciate the work to make this plugin exist! not sure if this is a feature request of perhaps evidence I need to debug my issue further, but my log is filled with the following repeating error: From what I can tell, everything is working properly despite these errors, and after searching forums, the only advice I can find related to these errors is to ignore them. I believe I have verified that I am using the correct driver for my USP (CyberPower CP1500PFCRM2U) Would it be possible to have an option to suppress these errors in the syslog at the plugin level, if they are indeed 'ignorable' ? Also, on my other Unraid server that is set as slave, again.... I am receiving UPS metrics and looks good across the board, however, my log is flooded with intermittent entries like this: Is there a value I should be changing to address this? maybe it's polling too frequently and failing intermittently due to that?

Yes this stopped docker from filling up! seems the template side of the mapping for appdata is indeed incorrect

Thanks @Kilrah, I guess I had assumed this thread is where the owner of the template may see this and be able to help! FWIW, based on the doc you shared I manually changed the template path of 'appdata' container path from /prometheus/data to just /prometheus, and I now see files populating as I'd expect inside of the 'data' folder, inside my appdata folder. I'll monitor if this edit resolves the docker image growth issue. This is a bit of trial & error on my part, so hopefully the template owner will verify this action if they see this!

hey @Kilrah, what I'm experiencing makes sense if the data is stored inside of /prometheus, but that seems to differ from the templated docker image from community applications?

Hey folks, I'm troubleshooting an issue of my docker image filling up pretty quickly, and I believe I've traced it to the prometheus docker. With the docker enabled with 3 monitors, my docker image went from 8.2GiB to 9.2GiB over the course of just a few hours. When the docker is disabled, the size stops growing (and actually recedes slightly). Based on troubleshooting guides, I expected to find a mismatched path in the docker, however, they are set as follows: appdata: /mnt/user/appdata/prometheus/data config: /mnt/user/appdata/prometheus/etc Etc has prometheus.yml, but the data directory is empty? is that normal? Is there an additional mapping my template is missing? Or, is there some additional config inside of prometheus I am failing to configure? I'm not too familiar with the app, if it's supposed to behave this way with some kind of retention policy, is that something I can adjust? when I noticed the issue, my docker had grown to 17GiB! Many thanks

Seems the null value beneath it was a red herring - I remembered that I had a user script starting powertop on array start and disabling that has so far returned stability, need to monitor for a few days! thank you for your patience and the troubleshooting steps!

As an experiment, I replaced both 'docker.cfg' and 'network.cfg' from the clean Unraid install template, and my new docker.cfg looks quite different upon starting the array: DOCKER_ENABLED="yes" DOCKER_IMAGE_FILE="/mnt/user/system/docker/docker.img" DOCKER_IMAGE_SIZE="20" DOCKER_APP_CONFIG_PATH="/mnt/user/appdata/" DOCKER_APP_UNRAID_PATH="" DOCKER_READMORE="yes" DOCKER_NETWORK_TYPE="1" I don't see 'DOCKER_CUSTOM_NETWORKS=" "' any longer either... were the other values redundant/retired? Edit - Gah, after about 10 minutes the system froze up again. Booting into safemode now as per your suggestion. Edit 2 - After booting in safe mode, guess what's back in my docker.cfg: DOCKER_ENABLED="no" DOCKER_IMAGE_FILE="/mnt/user/system/docker/docker.img" DOCKER_IMAGE_SIZE="20" DOCKER_APP_CONFIG_PATH="/mnt/user/appdata/" DOCKER_APP_UNRAID_PATH="" DOCKER_READMORE="yes" DOCKER_NETWORK_TYPE="1" DOCKER_CUSTOM_NETWORKS=" " DOCKER_TIMEOUT="10" Maybe I'm barking up the tree with that value, but why does it so randomly appear at different stages of this debugging journey?

Hey @JorgeB, I replaced my PSU and USB stick again this week but the problem persists - my first boot with the new hardware, I verified that Docker was set to ipvlan and started the array. Within a few moments it crashed. On the next boot, I went back to view docker settings, and as expected, the network type has reverted to macvlan - see image below. Any possible explanation for why this in particular seems to be resetting? if my docker.cfg or network settings are somehow corrupted, is there a way to restore? not making a lot of sense to me right now. This server has been running for many years, with lots of er, tinkering throughout that time it's quite possible I've done something odd with my network configs too, per edit 2 below. Any best practice to eliminate possible issues here? Edit - added diagnostics and the docker (after).cfg file from the flash, obtained on the 2nd boot. I also included docker (before) which is a copy of what I moved to my new flash drive last night. - you can see that a bunch of the docker settings are absent in the 'after' file. Edit 2 - looking at my docker (before), is DOCKER_CUSTOM_NETWORKS=" " a valid value to have in there? seems to be where the files first differ nostromo-diagnostics-20230923-0928.zip docker (before).cfg docker (after).cfg

Thanks @JorgeB, I do see 'DOCKER_NETWORK_TYPE="1"' in the current docker.cfg file, so I'll keep an eye on it in future. I'm fairly sure my docker.cfg file keeps getting reset, I'v included docker.cfg from an export a week prior and it has significantly less values in the file for some reason. My syslog is sent to my 2nd unraid server, linked below - I never see meaningful syslog entries when the crash occurs, the last crash was at 'Sep 16 13:16:15'. I've also attached the syslog directly from the crashing server (Nostromo), after the last crash hope these help. volta-syslog-10.168.1.90-20230917-1330.zip nostromo-syslog-20230916-1728.zip docker.cfg

Hey folks, my server is inconsistently freezing a few minutes after boot/enabling docker. I've posted previously about an error in the log (here) with no response, but this seems to be related to docker/network settings. As per recommendation of upgrading to 6.12.4, I have docker configured to use ipvlan which has worked fine - when the sever does not crash within the first 10mins of booting, it will run perfectly until the next time I manually shutdown/reboot for maintenance. I have however noticed that after a reboot, the docker network setting is reverting to maclan - possibly I'm not noticing this everytime it reverts and could be the times it freezes up? not sure. I'm also suspicious of my USB flash drive which is a new replacement about 2 weeks ago after the prior seemed to become faulty. Where in the USB drive would this 'ipvlan' setting be, so I can explore closer? Any support/suggestions appreciated, diagnostics attached. nostromo-diagnostics-20230916-1220.zip

That is my TrueNAS server, connected via SMB shares. Has been working fine until last update.

Voila! nostromo-diagnostics-20230830-1040.zip