Fribb

Because of this, My backup has failed for 4 days in a row. Is there any solution?

I currently have an issue in which my backups fail because, from what I can tell, the verification of the backup of some docker containers fails. This isn't exclusive to certain containers but rather happens with a bunch of them, one day one fails, the next day everything works fine, another day some other fails. But whenever it fails, it is always the same process, here is an example: First, it tries to stop the container which, for some reason, doesn't work [10.12.2024 00:10:02][ℹ️][plex] Stopping plex... Error while stopping container! Code: Container already started - trying 'docker stop' method [10.12.2024 00:10:02][ℹ️][plex] That _seemed_ to work. then it does the backup and the TAR verification fails [10.12.2024 00:42:59][ℹ️][plex] Should NOT backup external volumes, sanitizing them... [10.12.2024 00:42:59][ℹ️][plex] Calculated volumes to back up: /mnt/user/appdata/plex [10.12.2024 00:42:59][ℹ️][plex] Backing up plex... [10.12.2024 01:15:30][ℹ️][plex] Backup created without issues (took 00:32:31 (hours:mins:secs)) [10.12.2024 01:15:30][ℹ️][plex] Verifying backup... [10.12.2024 01:22:46][❌][plex] tar verification failed! ... [10.12.2024 01:24:31][ℹ️][plex] Installing planned update for plex... I don't know why the stopping of the container would fail since there is no error being logged. However, it seems that the verification failed because the backup was done while the container was running. At least that is what I am guessing because the verification failed and also states "Contents differ". I also tried to help the plugin out by stopping all running containers in a pre-run script but with the command listed below, it says the following log message. #! /bin/bash docker stop $(docker ps -a -q) [10.12.2024 00:00:02][ℹ️][Main] Executing script '/mnt/user/appdata/pre-run-backup.sh' 'pre-run' '/mnt/user/system-backup/appdata/ab_20241210_000002'... [10.12.2024 00:00:02][ℹ️][Main] Script executed! [10.12.2024 00:00:02][⚠️][Main] Script did not returned 0 (it returned 127)! Which, to my knowledge, that return code 127 means that it is a "command not found". I mean the command itself runs without issues, I also have executed the script manually and it does what it is supposed to do without issues. How can the docker command not be found? Is the script executed in some way that some basic Unraid parts are not available? This whole thing raises some questions for me: Why is the log message "Container already started" when there is a log message of "stopping the container"? Apparently, the "docker stop" command never works (for me) even though it says that it "seems to work". (there is no restart=always or anything like that on the docker container). If this isn't "docker stop" that is attempted here, what is being used here to stop the containers? Why is a simple pre-run script with "docker stop" returning 127 instead of 0 even though I can execute it just fine manually?

Thank you, that was it. I don't know why that was set to '192.168.1.0/24'. set that to my correct LAN network and now it works.

yeah, this isn't any different to what I did. Wireguard and the VPN work fine, the curled IP from ifconfig.co/ip is different to the one I get in just my regular browser. However, the WebUI of Qbit is not accessible for whatever reason the only errors in the linked log file are Standard error outputs from the Start Script which don't look like errors to me.

In the Readme in the WireGuard Section

With the PIA/OPENVPN issue, I wanted to try out Wireguard but just following the README didn't work. Setting VPN_CLIENT to wireguard, running the container in privileged mode and setting sysctl="net.ipv4.conf.all.src_valid_mark=1" will result in the container being started but the WebUI runs into a timeout. Here are the startup parameters 2024-05-03 12:46:15.308638 [info] Host is running unRAID 2024-05-03 12:46:15.330047 [info] System information Linux 90a76e02267e 6.1.64-Unraid #1 SMP PREEMPT_DYNAMIC Wed Nov 29 12:48:16 PST 2023 x86_64 GNU/Linux 2024-05-03 12:46:15.354886 [info] PUID defined as '99' 2024-05-03 12:46:15.432609 [info] PGID defined as '100' 2024-05-03 12:46:15.531275 [info] UMASK defined as '000' 2024-05-03 12:46:15.553667 [info] Permissions already set for '/config' 2024-05-03 12:46:15.578096 [info] Deleting files in /tmp (non recursive)... 2024-05-03 12:46:15.609182 [info] VPN_ENABLED defined as 'yes' 2024-05-03 12:46:15.633233 [info] VPN_CLIENT defined as 'wireguard' 2024-05-03 12:46:15.656610 [info] VPN_PROV defined as 'pia' 2024-05-03 12:46:15.687296 [info] WireGuard config file (conf extension) is located at /config/wireguard/wg0.conf 2024-05-03 12:46:15.718762 [info] VPN_REMOTE_SERVER defined as 'nl-amsterdam.privacy.network' 2024-05-03 12:46:15.744488 [info] VPN_REMOTE_PORT defined as '1337' 2024-05-03 12:46:15.765793 [info] VPN_DEVICE_TYPE defined as 'wg0' 2024-05-03 12:46:15.787013 [info] VPN_REMOTE_PROTOCOL defined as 'udp' 2024-05-03 12:46:46.159324 [info] LAN_NETWORK defined as '192.168.1.0/24' 2024-05-03 12:46:46.187446 [info] LAN_NETWORK exported as '192.168.1.0/24' 2024-05-03 12:46:46.210320 [info] NAME_SERVERS defined as '84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1' 2024-05-03 12:46:46.233490 [info] VPN_USER defined as 'redacted' 2024-05-03 12:46:46.256255 [info] VPN_PASS defined as 'redacted' 2024-05-03 12:46:46.279149 [info] STRICT_PORT_FORWARD defined as 'yes' 2024-05-03 12:46:46.302224 [info] ENABLE_PRIVOXY defined as 'yes' 2024-05-03 12:46:46.327174 [info] VPN_INPUT_PORTS not defined (via -e VPN_INPUT_PORTS), skipping allow for custom incoming ports 2024-05-03 12:46:46.350626 [info] VPN_OUTPUT_PORTS not defined (via -e VPN_OUTPUT_PORTS), skipping allow for custom outgoing ports 2024-05-03 12:46:46.373783 [info] ENABLE_STARTUP_SCRIPTS not defined (via -e ENABLE_STARTUP_SCRIPTS), defaulting to 'no' 2024-05-03 12:46:46.396916 [info] WEBUI_PORT defined as '8085' 2024-05-03 12:46:46.435452 [info] Starting Supervisor... When I run the same configuration with just OpenVPN instead of wireguard, as soon as I get the 2024-05-03 12:57:58,270 DEBG 'watchdog-script' stdout output: [info] qBittorrent process listening on port 8085 log output, I can access the WebUI. When I change VPN_CLIENT to wireguard, the same log output happens but the WebUI is running in the timeout. full log output with redacted possibly private information https://pastebin.com/avNzwj9g

Interesting, I disabled the UPS Settings and NUT seems to show everything again. Though I am wondering why it worked for a year and just now wants to crap the bed... Thanks for the easy fix.

This morning I got the message "Warning communication lost with UPS". I checked my NUT Settings and the UPS is listed as "On Line" with battery charge and NUT Details. But in the UPS settings it states "Lost communication". I already restarted both services and also switched USB ports without any change. I do see a few warnings in the syslog like "Poll UPS failed - Data stale" or when I restart the NUT service I get "WARNING: send_to_all: write 34 bytes to socket 16 failed (ret=-1), disconnecting: Broken pipe" diagnostics are attached. I have the CyberPower CP1500EPFCLCD for a year now which was running without any issues. fribb-tower-diagnostics-20231119-0502.zip

I would like to make a suggestion. While I like the "container by container" approach of doing the backups to reduce the time a container isn't available, in some instances this could also be a problem. For example, stopping the database of a service will potentially break the service accessing that database. A more specific example, I have a Tautulli container which can monitor the Plex logs which are acessible through a volume mapping to the Plex container config. However, currently the Backup of Tautulli fails because the Plex Logs are changing. I had to now remove that feature and the volume mapping for Tautulli getting backed up correctly. I also see that a ToDo is to "Use Dockerman default order when no order was set before" which is good but doesn't necessarily fix the issue I highlighted above. What I would like to see is that you can "group" Containers so that they are stopped as a whole and then started after they are backed up. So, for example, Plex and Tautulli are in such a group and both are getting stopped, Tautulli is backed-up and started, then Plex is backed-up and started.

Yes, I'm really really sure that I booted into UEFI before. I think I even read somewhere that you should use UEFI because that is the new standard?! I had it on the old board, running 6.8.3 and the new board running 6.8.3 and 6.9-rc2 but on 6.8.3 I had the "old" Nvidia approach which I can't reproduce anymore because of missing drivers etc or I would have tried to see if that is a problem there too and my GPU has some issues. While testing the new components for my DAS I had the old board and even plugged the GPU into it and ran some transcodes without that problem turning up. Whatever the case, running in legacy seems to have fixed that for whatever reason.

I'm pretty sure, yes. So, the transcodes are through, no GUI mode, persistance mode 1 and loaded with Legacy. Seems to run as it should but I will keep and eye/ear on it but hopefully it will stay that way. Still, why did it work before and not now anymore?

So, I booted in legacy mode and with GUI and let some ffmpeg transcodes running, GPU went up to 62°C and stayed there while the fan was at 40%. So far, hopefully I don't jinx it with saying that, the GPU has stayed quiet and at 35% fan speed. What is weird to me is that I didn't had this behaviour the last year and only recently after upgrading to 6.9 (and switching Motherboards), I already have the latest bios on the MB.

I meant a previous driver version because I didn't had this issue a couple of weeks ago. I don't know when the v455.45.01 so this might just me grasping at straws. This is a GPU I use/used for a year now in the same server and only recently when I did my DAS server expansion and upgrade to 6.9 had this problem. I did try it with a different board while testing the DAS hardware and the problem didn't turn up there for some reason (also Unraid 6.9 and v455.45.01). I did run it with GUI mode for a while and it seemed to not happen there but I did not extensively test it as I did today running a few ffmpeg transcodes. I boot with UEFI mode. I already had the persistance mode active and also disabled and enabled it a couple of times trying to figure this out, without any luck. Now that I stopped the array it suddenly stopped and after a couple of minutes it started again. Disabled the 2 docker containers that have the GPU passed through and it dipped shortly but stayed at max fan speed. I rebooted in GUI mode now and the Fan has settled down again, I have to do some tests first to be sure that it is "working". Though I don't know if that should be the solution...

I have some issue with my 1660 Super. When the GPU is is under load it will go up to 60°C and hover around 40% fan power. After a while, after the GPU has a load of 0%, the temperature is back to normal 36°C and it is in P8 power state the fan decides to spin up to 100-110% and stay there for a while. After a short or long while (currently active for 10 minutes) it will settle down again but shortly after will ramp up again. I got the latest drive v455.45.01 installed and am wondering if there is a way to install a previous version just to rule out any issues with the driver itself. I'm running Unraid 6.9.0-rc2, the GPU is at 8 lanes if that makes any difference. I would restart but I have a few pre-clears running which will still take a few hours.