Fredrick
-
Posts
173 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Fredrick
-
-
I cant get this to work, I don't understand why I cant access the server once it's running. I'm pretty well versed in port forwarding, and I've tried both bridge, host and a separate br0-network connection.
I might be misunderstanding something here, but why is the template set up with port 19137 here? It's the same for the UDP-port.
EDIT: Removed the image and installed fresh from community applications and it's correctly showing 19132 again now. I still cant see the port working on canyouseeme.org though..
Here is my port-forward-rules on my Dream Machine:
Docker-settings:
-
Hi guys,
I've got a NIC with 4x GbE (plus another one in the motherboard), and I want to make sure that my config makes sense. I can patch them all up in a managed switch if need be.
First of all I need a solid connection to Unraid. Thinking about dedicating 2 of the ports to a failover-bridge for Unraid. I might even patch one of the connections up in my router to have a failover even in case the switch should die on me.
Secondly I've got a VM that I want on a separate VLAN. Should I put a port on the NIC on that VLAN, and use that port for the VM?
Thirdly I've got a Pihole docker with it's own IP. I've previously and successfully run this on the bridge set up for Unraid, with a fixed IP in the Docker settings. Is there any pros of moving it to a dedicated port?
Open to ideas or input, this is not really a territory I know much about
-
This has happend to me too. Did you ever solve it @Convington?
-
On 11/8/2021 at 9:17 AM, Luddi said:
I noticed the same thing after updating and thereby restarting the container. The problem was that /var/lib/influxdb2 in the container was not mapped to a path on the host. This path is new in addition to /var/lib/influxdb. See Upgrade Example - Minimal here for example.
This didn't work for me. The entire /mnt/user/appdata/influxdb folder has been wiped for me, I don't know how that could have happend during the update.
Just to be clear this was already a InfluxDB v2 docker, it just updated to a newer build
Any ideas?
-
5 hours ago, Squid said:
The logs would have stated that an error of some sort happened during the backups. In an error situation, the old backup sets don't get deleted. This is why your earliest set 4/25 still exists. Pretty sure that a notification goes out in the error situation
I believe the relevant portion of the log is in the spoiler. I don't see any errors indicated here, and the pushover notification definitely says Backup Complete. No trace of what happend with influx either.
Running Unraid 6.9.2, plugin dated 2021.03.13 which I see isn't the newest.
EDIT: I didn't find the correct line earlier. It does in fact indicate that the source couldn't be found, which is because I've moved my appdata from /mnt/cache/appdata to a new nvme disk at /mnt/cache_nvme/appdata. Oops.. Still no clue why Influxdb messed up so bad
EDIT2: It's obviously much better to backup /mnt/user/appdata than pointing it directly to the drives. I don't know what I was thinking when I set it up..
SpoilerNov 25 04:00:01 Tower CA Backup/Restore: ####################################### Nov 25 04:00:01 Tower CA Backup/Restore: Community Applications appData Backup Nov 25 04:00:01 Tower CA Backup/Restore: Applications will be unavailable during Nov 25 04:00:01 Tower CA Backup/Restore: this process. They will automatically Nov 25 04:00:01 Tower CA Backup/Restore: be restarted upon completion. Nov 25 04:00:01 Tower CA Backup/Restore: ####################################### Nov 25 04:00:01 Tower CA Backup/Restore: Stopping binhex-krusader Nov 25 04:00:02 Tower kernel: docker0: port 19(vethc3b91c6) entered disabled state Nov 25 04:00:02 Tower kernel: vethb09ae0e: renamed from eth0 Nov 25 04:00:02 Tower avahi-daemon[11847]: Interface vethc3b91c6.IPv6 no longer relevant for mDNS. Nov 25 04:00:02 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethc3b91c6.IPv6 with address fe80::c8bc:f6ff:fe11:2dd0. Nov 25 04:00:02 Tower kernel: docker0: port 19(vethc3b91c6) entered disabled state Nov 25 04:00:02 Tower kernel: device vethc3b91c6 left promiscuous mode Nov 25 04:00:02 Tower kernel: docker0: port 19(vethc3b91c6) entered disabled state Nov 25 04:00:02 Tower avahi-daemon[11847]: Withdrawing address record for fe80::c8bc:f6ff:fe11:2dd0 on vethc3b91c6. Nov 25 04:00:02 Tower CA Backup/Restore: docker stop -t 60 binhex-krusader Nov 25 04:00:02 Tower CA Backup/Restore: Stopping binhex-plexpass Nov 25 04:00:04 Tower CA Backup/Restore: docker stop -t 60 binhex-plexpass Nov 25 04:00:04 Tower CA Backup/Restore: Stopping Dozzle Nov 25 04:00:04 Tower kernel: docker0: port 18(vethc03ad45) entered disabled state Nov 25 04:00:04 Tower kernel: veth1beb0cc: renamed from eth0 Nov 25 04:00:04 Tower avahi-daemon[11847]: Interface vethc03ad45.IPv6 no longer relevant for mDNS. Nov 25 04:00:04 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethc03ad45.IPv6 with address fe80::78ab:aaff:fe16:3d85. Nov 25 04:00:04 Tower kernel: docker0: port 18(vethc03ad45) entered disabled state Nov 25 04:00:04 Tower kernel: device vethc03ad45 left promiscuous mode Nov 25 04:00:04 Tower kernel: docker0: port 18(vethc03ad45) entered disabled state Nov 25 04:00:04 Tower avahi-daemon[11847]: Withdrawing address record for fe80::78ab:aaff:fe16:3d85 on vethc03ad45. Nov 25 04:00:04 Tower CA Backup/Restore: docker stop -t 60 Dozzle Nov 25 04:00:04 Tower CA Backup/Restore: Stopping Grafana Nov 25 04:00:04 Tower kernel: docker0: port 1(veth6d0cfee) entered disabled state Nov 25 04:00:04 Tower kernel: veth607e372: renamed from eth0 Nov 25 04:00:04 Tower avahi-daemon[11847]: Interface veth6d0cfee.IPv6 no longer relevant for mDNS. Nov 25 04:00:04 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth6d0cfee.IPv6 with address fe80::942e:c1ff:feb9:64eb. Nov 25 04:00:04 Tower kernel: docker0: port 1(veth6d0cfee) entered disabled state Nov 25 04:00:04 Tower kernel: device veth6d0cfee left promiscuous mode Nov 25 04:00:04 Tower kernel: docker0: port 1(veth6d0cfee) entered disabled state Nov 25 04:00:04 Tower avahi-daemon[11847]: Withdrawing address record for fe80::942e:c1ff:feb9:64eb on veth6d0cfee. Nov 25 04:00:04 Tower CA Backup/Restore: docker stop -t 60 Grafana Nov 25 04:00:04 Tower CA Backup/Restore: Stopping habridge Nov 25 04:00:13 Tower kernel: veth9c4dacc: renamed from eth0 Nov 25 04:00:13 Tower CA Backup/Restore: docker stop -t 60 habridge Nov 25 04:00:13 Tower CA Backup/Restore: Stopping Influxdb2 Nov 25 04:00:13 Tower kernel: docker0: port 2(veth76f0742) entered disabled state Nov 25 04:00:13 Tower kernel: veth2458fd8: renamed from eth0 Nov 25 04:00:13 Tower avahi-daemon[11847]: Interface veth76f0742.IPv6 no longer relevant for mDNS. Nov 25 04:00:13 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth76f0742.IPv6 with address fe80::9893:99ff:fed8:fdaf. Nov 25 04:00:13 Tower kernel: docker0: port 2(veth76f0742) entered disabled state Nov 25 04:00:13 Tower kernel: device veth76f0742 left promiscuous mode Nov 25 04:00:13 Tower kernel: docker0: port 2(veth76f0742) entered disabled state Nov 25 04:00:13 Tower avahi-daemon[11847]: Withdrawing address record for fe80::9893:99ff:fed8:fdaf on veth76f0742. Nov 25 04:00:13 Tower CA Backup/Restore: docker stop -t 60 Influxdb2 Nov 25 04:00:13 Tower CA Backup/Restore: Stopping jackett Nov 25 04:00:17 Tower kernel: docker0: port 3(vethf5c6fc1) entered disabled state Nov 25 04:00:17 Tower kernel: vethcf13e3a: renamed from eth0 Nov 25 04:00:17 Tower avahi-daemon[11847]: Interface vethf5c6fc1.IPv6 no longer relevant for mDNS. Nov 25 04:00:17 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethf5c6fc1.IPv6 with address fe80::60c6:49ff:fe7b:6cf2. Nov 25 04:00:17 Tower kernel: docker0: port 3(vethf5c6fc1) entered disabled state Nov 25 04:00:17 Tower kernel: device vethf5c6fc1 left promiscuous mode Nov 25 04:00:17 Tower kernel: docker0: port 3(vethf5c6fc1) entered disabled state Nov 25 04:00:17 Tower avahi-daemon[11847]: Withdrawing address record for fe80::60c6:49ff:fe7b:6cf2 on vethf5c6fc1. Nov 25 04:00:17 Tower CA Backup/Restore: docker stop -t 60 jackett Nov 25 04:00:17 Tower CA Backup/Restore: Stopping letsencrypt Nov 25 04:00:20 Tower kernel: docker0: port 4(veth250f602) entered disabled state Nov 25 04:00:20 Tower kernel: vethb404b7c: renamed from eth0 Nov 25 04:00:20 Tower avahi-daemon[11847]: Interface veth250f602.IPv6 no longer relevant for mDNS. Nov 25 04:00:20 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth250f602.IPv6 with address fe80::9836:4bff:fed2:15c0. Nov 25 04:00:20 Tower kernel: docker0: port 4(veth250f602) entered disabled state Nov 25 04:00:20 Tower kernel: device veth250f602 left promiscuous mode Nov 25 04:00:20 Tower kernel: docker0: port 4(veth250f602) entered disabled state Nov 25 04:00:20 Tower avahi-daemon[11847]: Withdrawing address record for fe80::9836:4bff:fed2:15c0 on veth250f602. Nov 25 04:00:20 Tower CA Backup/Restore: docker stop -t 60 letsencrypt Nov 25 04:00:20 Tower CA Backup/Restore: Stopping mariadb Nov 25 04:00:24 Tower kernel: docker0: port 5(vethae2df10) entered disabled state Nov 25 04:00:24 Tower kernel: veth03cd18d: renamed from eth0 Nov 25 04:00:24 Tower avahi-daemon[11847]: Interface vethae2df10.IPv6 no longer relevant for mDNS. Nov 25 04:00:24 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethae2df10.IPv6 with address fe80::2898:ceff:feee:fa04. Nov 25 04:00:24 Tower kernel: docker0: port 5(vethae2df10) entered disabled state Nov 25 04:00:24 Tower kernel: device vethae2df10 left promiscuous mode Nov 25 04:00:24 Tower kernel: docker0: port 5(vethae2df10) entered disabled state Nov 25 04:00:24 Tower avahi-daemon[11847]: Withdrawing address record for fe80::2898:ceff:feee:fa04 on vethae2df10. Nov 25 04:00:24 Tower CA Backup/Restore: docker stop -t 60 mariadb Nov 25 04:00:24 Tower CA Backup/Restore: Stopping MQTT Nov 25 04:00:24 Tower kernel: veth9d6007a: renamed from eth0 Nov 25 04:00:24 Tower kernel: docker0: port 6(veth847425e) entered disabled state Nov 25 04:00:24 Tower avahi-daemon[11847]: Interface veth847425e.IPv6 no longer relevant for mDNS. Nov 25 04:00:24 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth847425e.IPv6 with address fe80::8cdd:a1ff:fee5:7508. Nov 25 04:00:24 Tower kernel: docker0: port 6(veth847425e) entered disabled state Nov 25 04:00:24 Tower kernel: device veth847425e left promiscuous mode Nov 25 04:00:24 Tower kernel: docker0: port 6(veth847425e) entered disabled state Nov 25 04:00:24 Tower avahi-daemon[11847]: Withdrawing address record for fe80::8cdd:a1ff:fee5:7508 on veth847425e. Nov 25 04:00:24 Tower CA Backup/Restore: docker stop -t 60 MQTT Nov 25 04:00:24 Tower CA Backup/Restore: Stopping nextcloud Nov 25 04:00:28 Tower kernel: docker0: port 7(veth44b9231) entered disabled state Nov 25 04:00:28 Tower kernel: vethb3c4626: renamed from eth0 Nov 25 04:00:28 Tower avahi-daemon[11847]: Interface veth44b9231.IPv6 no longer relevant for mDNS. Nov 25 04:00:28 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth44b9231.IPv6 with address fe80::f42f:cff:fea2:dae. Nov 25 04:00:28 Tower kernel: docker0: port 7(veth44b9231) entered disabled state Nov 25 04:00:28 Tower kernel: device veth44b9231 left promiscuous mode Nov 25 04:00:28 Tower kernel: docker0: port 7(veth44b9231) entered disabled state Nov 25 04:00:28 Tower avahi-daemon[11847]: Withdrawing address record for fe80::f42f:cff:fea2:dae on veth44b9231. Nov 25 04:00:28 Tower CA Backup/Restore: docker stop -t 60 nextcloud Nov 25 04:00:28 Tower CA Backup/Restore: Stopping nzbget Nov 25 04:00:32 Tower kernel: docker0: port 8(veth22d80b0) entered disabled state Nov 25 04:00:32 Tower kernel: veth1ad5fb5: renamed from eth0 Nov 25 04:00:32 Tower avahi-daemon[11847]: Interface veth22d80b0.IPv6 no longer relevant for mDNS. Nov 25 04:00:32 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth22d80b0.IPv6 with address fe80::60d3:11ff:fe8f:5971. Nov 25 04:00:32 Tower kernel: docker0: port 8(veth22d80b0) entered disabled state Nov 25 04:00:32 Tower kernel: device veth22d80b0 left promiscuous mode Nov 25 04:00:32 Tower kernel: docker0: port 8(veth22d80b0) entered disabled state Nov 25 04:00:32 Tower avahi-daemon[11847]: Withdrawing address record for fe80::60d3:11ff:fe8f:5971 on veth22d80b0. Nov 25 04:00:32 Tower CA Backup/Restore: docker stop -t 60 nzbget Nov 25 04:00:32 Tower CA Backup/Restore: Stopping nzbhydra2 Nov 25 04:00:37 Tower kernel: docker0: port 9(veth9444825) entered disabled state Nov 25 04:00:37 Tower kernel: vethcc3e6b8: renamed from eth0 Nov 25 04:00:37 Tower avahi-daemon[11847]: Interface veth9444825.IPv6 no longer relevant for mDNS. Nov 25 04:00:37 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth9444825.IPv6 with address fe80::183f:64ff:fe8c:e9ff. Nov 25 04:00:37 Tower kernel: docker0: port 9(veth9444825) entered disabled state Nov 25 04:00:37 Tower kernel: device veth9444825 left promiscuous mode Nov 25 04:00:37 Tower kernel: docker0: port 9(veth9444825) entered disabled state Nov 25 04:00:37 Tower avahi-daemon[11847]: Withdrawing address record for fe80::183f:64ff:fe8c:e9ff on veth9444825. Nov 25 04:00:37 Tower CA Backup/Restore: docker stop -t 60 nzbhydra2 Nov 25 04:00:37 Tower CA Backup/Restore: Stopping ombi Nov 25 04:00:41 Tower kernel: docker0: port 10(veth1817c01) entered disabled state Nov 25 04:00:41 Tower kernel: vethde6851f: renamed from eth0 Nov 25 04:00:41 Tower avahi-daemon[11847]: Interface veth1817c01.IPv6 no longer relevant for mDNS. Nov 25 04:00:41 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth1817c01.IPv6 with address fe80::60ed:f5ff:fe4b:d5f5. Nov 25 04:00:41 Tower kernel: docker0: port 10(veth1817c01) entered disabled state Nov 25 04:00:41 Tower kernel: device veth1817c01 left promiscuous mode Nov 25 04:00:41 Tower kernel: docker0: port 10(veth1817c01) entered disabled state Nov 25 04:00:41 Tower avahi-daemon[11847]: Withdrawing address record for fe80::60ed:f5ff:fe4b:d5f5 on veth1817c01. Nov 25 04:00:41 Tower CA Backup/Restore: docker stop -t 60 ombi Nov 25 04:00:41 Tower CA Backup/Restore: Stopping Organizr Nov 25 04:00:45 Tower kernel: docker0: port 11(veth8771336) entered disabled state Nov 25 04:00:45 Tower kernel: vethf9b0110: renamed from eth0 Nov 25 04:00:45 Tower avahi-daemon[11847]: Interface veth8771336.IPv6 no longer relevant for mDNS. Nov 25 04:00:45 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth8771336.IPv6 with address fe80::bcf9:c1ff:fe88:9f67. Nov 25 04:00:45 Tower kernel: docker0: port 11(veth8771336) entered disabled state Nov 25 04:00:45 Tower kernel: device veth8771336 left promiscuous mode Nov 25 04:00:45 Tower kernel: docker0: port 11(veth8771336) entered disabled state Nov 25 04:00:45 Tower avahi-daemon[11847]: Withdrawing address record for fe80::bcf9:c1ff:fe88:9f67 on veth8771336. Nov 25 04:00:45 Tower CA Backup/Restore: docker stop -t 60 Organizr Nov 25 04:00:45 Tower CA Backup/Restore: Stopping pihole2 Nov 25 04:00:48 Tower kernel: device br0 left promiscuous mode Nov 25 04:00:48 Tower kernel: vethb8d4ae9: renamed from eth0 Nov 25 04:00:48 Tower CA Backup/Restore: docker stop -t 60 pihole2 Nov 25 04:00:48 Tower CA Backup/Restore: Stopping qbittorrent Nov 25 04:00:55 Tower kernel: docker0: port 12(veth2aaf560) entered disabled state Nov 25 04:00:55 Tower kernel: veth10e20e2: renamed from eth0 Nov 25 04:00:55 Tower avahi-daemon[11847]: Interface veth2aaf560.IPv6 no longer relevant for mDNS. Nov 25 04:00:55 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth2aaf560.IPv6 with address fe80::400e:64ff:fea4:376c. Nov 25 04:00:55 Tower kernel: docker0: port 12(veth2aaf560) entered disabled state Nov 25 04:00:55 Tower kernel: device veth2aaf560 left promiscuous mode Nov 25 04:00:55 Tower kernel: docker0: port 12(veth2aaf560) entered disabled state Nov 25 04:00:55 Tower avahi-daemon[11847]: Withdrawing address record for fe80::400e:64ff:fea4:376c on veth2aaf560. Nov 25 04:00:55 Tower CA Backup/Restore: docker stop -t 60 qbittorrent Nov 25 04:00:55 Tower CA Backup/Restore: Stopping radarr Nov 25 04:00:57 Tower root: /etc/libvirt: 73.6 MiB (77156352 bytes) trimmed on /dev/loop3 Nov 25 04:00:57 Tower root: /var/lib/docker: 11.6 GiB (12492013568 bytes) trimmed on /dev/loop2 Nov 25 04:00:57 Tower root: /mnt/cache_nvme: 284.1 GiB (305059872768 bytes) trimmed on /dev/nvme0n1p1 Nov 25 04:00:57 Tower root: /mnt/cache: 11.2 GiB (12015661056 bytes) trimmed on /dev/sdl1 Nov 25 04:00:58 Tower kernel: docker0: port 13(vethbc43fdc) entered disabled state Nov 25 04:00:58 Tower kernel: veth68b43ca: renamed from eth0 Nov 25 04:00:59 Tower avahi-daemon[11847]: Interface vethbc43fdc.IPv6 no longer relevant for mDNS. Nov 25 04:00:59 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethbc43fdc.IPv6 with address fe80::e05e:d0ff:fee2:f32d. Nov 25 04:00:59 Tower kernel: docker0: port 13(vethbc43fdc) entered disabled state Nov 25 04:00:59 Tower kernel: device vethbc43fdc left promiscuous mode Nov 25 04:00:59 Tower kernel: docker0: port 13(vethbc43fdc) entered disabled state Nov 25 04:00:59 Tower avahi-daemon[11847]: Withdrawing address record for fe80::e05e:d0ff:fee2:f32d on vethbc43fdc. Nov 25 04:00:59 Tower CA Backup/Restore: docker stop -t 60 radarr Nov 25 04:00:59 Tower CA Backup/Restore: Stopping Sonarr Nov 25 04:01:02 Tower kernel: docker0: port 14(vethdaa15b7) entered disabled state Nov 25 04:01:02 Tower kernel: veth7bde32e: renamed from eth0 Nov 25 04:01:02 Tower avahi-daemon[11847]: Interface vethdaa15b7.IPv6 no longer relevant for mDNS. Nov 25 04:01:02 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethdaa15b7.IPv6 with address fe80::f8d5:88ff:fef1:36e0. Nov 25 04:01:02 Tower kernel: docker0: port 14(vethdaa15b7) entered disabled state Nov 25 04:01:02 Tower kernel: device vethdaa15b7 left promiscuous mode Nov 25 04:01:02 Tower kernel: docker0: port 14(vethdaa15b7) entered disabled state Nov 25 04:01:02 Tower avahi-daemon[11847]: Withdrawing address record for fe80::f8d5:88ff:fef1:36e0 on vethdaa15b7. Nov 25 04:01:02 Tower CA Backup/Restore: docker stop -t 60 Sonarr Nov 25 04:01:02 Tower CA Backup/Restore: Stopping Stash Nov 25 04:01:02 Tower kernel: docker0: port 15(veth73d1761) entered disabled state Nov 25 04:01:02 Tower kernel: veth114543d: renamed from eth0 Nov 25 04:01:02 Tower avahi-daemon[11847]: Interface veth73d1761.IPv6 no longer relevant for mDNS. Nov 25 04:01:02 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface veth73d1761.IPv6 with address fe80::3487:a4ff:feb2:4c68. Nov 25 04:01:02 Tower kernel: docker0: port 15(veth73d1761) entered disabled state Nov 25 04:01:02 Tower kernel: device veth73d1761 left promiscuous mode Nov 25 04:01:02 Tower kernel: docker0: port 15(veth73d1761) entered disabled state Nov 25 04:01:02 Tower avahi-daemon[11847]: Withdrawing address record for fe80::3487:a4ff:feb2:4c68 on veth73d1761. Nov 25 04:01:02 Tower CA Backup/Restore: docker stop -t 60 Stash Nov 25 04:01:02 Tower CA Backup/Restore: Stopping tautulli Nov 25 04:01:06 Tower kernel: docker0: port 16(vetha1a9ab9) entered disabled state Nov 25 04:01:06 Tower kernel: veth31dc015: renamed from eth0 Nov 25 04:01:06 Tower avahi-daemon[11847]: Interface vetha1a9ab9.IPv6 no longer relevant for mDNS. Nov 25 04:01:06 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vetha1a9ab9.IPv6 with address fe80::5845:1dff:fef8:ed78. Nov 25 04:01:06 Tower kernel: docker0: port 16(vetha1a9ab9) entered disabled state Nov 25 04:01:06 Tower kernel: device vetha1a9ab9 left promiscuous mode Nov 25 04:01:06 Tower kernel: docker0: port 16(vetha1a9ab9) entered disabled state Nov 25 04:01:06 Tower avahi-daemon[11847]: Withdrawing address record for fe80::5845:1dff:fef8:ed78 on vetha1a9ab9. Nov 25 04:01:06 Tower CA Backup/Restore: docker stop -t 60 tautulli Nov 25 04:01:06 Tower CA Backup/Restore: Stopping telegraf Nov 25 04:01:06 Tower CA Backup/Restore: docker stop -t 60 telegraf Nov 25 04:01:06 Tower CA Backup/Restore: Stopping unifi-controller Nov 25 04:01:20 Tower kernel: docker0: port 17(vethdea285a) entered disabled state Nov 25 04:01:20 Tower kernel: vetha9b79cb: renamed from eth0 Nov 25 04:01:20 Tower avahi-daemon[11847]: Interface vethdea285a.IPv6 no longer relevant for mDNS. Nov 25 04:01:20 Tower avahi-daemon[11847]: Leaving mDNS multicast group on interface vethdea285a.IPv6 with address fe80::3cfe:83ff:fe44:78c6. Nov 25 04:01:20 Tower kernel: docker0: port 17(vethdea285a) entered disabled state Nov 25 04:01:20 Tower kernel: device vethdea285a left promiscuous mode Nov 25 04:01:20 Tower kernel: docker0: port 17(vethdea285a) entered disabled state Nov 25 04:01:20 Tower avahi-daemon[11847]: Withdrawing address record for fe80::3cfe:83ff:fe44:78c6 on vethdea285a. Nov 25 04:01:20 Tower CA Backup/Restore: docker stop -t 60 unifi-controller Nov 25 04:01:20 Tower CA Backup/Restore: Backing up USB Flash drive config folder to Nov 25 04:01:20 Tower CA Backup/Restore: Using command: /usr/bin/rsync -avXHq --delete --log-file="/var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log" /boot/ "/mnt/user/B../" > /dev/null 2>&1 Nov 25 04:01:30 Tower CA Backup/Restore: Changing permissions on backup Nov 25 04:01:30 Tower CA Backup/Restore: Backing up libvirt.img to /mnt/user/Backup/Unraid/librvirt/ Nov 25 04:01:30 Tower CA Backup/Restore: Using Command: /usr/bin/rsync -avXHq --delete --log-file="/var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log" "/mnt/user/s../" > /dev/null 2>&1 Nov 25 04:01:32 Tower CA Backup/Restore: Changing permissions on backup Nov 25 04:01:32 Tower CA Backup/Restore: Backing Up appData from /mnt/cache/appdata/ to /[email protected] Nov 25 04:01:32 Tower CA Backup/Restore: Appdata not backed up. Missing source Nov 25 04:01:32 Tower CA Backup/Restore: Using command: /usr/bin/rsync -avXHq --delete --log-file="/var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log" "/mnt/user/s../" > /dev/null 2>&1 Nov 25 04:01:32 Tower CA Backup/Restore: Backup Complete Nov 25 04:01:32 Tower CA Backup/Restore: Verifying backup Nov 25 04:01:32 Tower CA Backup/Restore: Using command: cd '/mnt/cache/appdata/' && /usr/bin/tar --diff -C '/mnt/cache/appdata/' -af '/[email protected]' > /var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log & echo $! > /tmp/ca.backup2/tempFiles/verifyInProgress Nov 25 04:01:32 Tower Docker Auto Update: Community Applications Docker Autoupdate running Nov 25 04:01:32 Tower Docker Auto Update: Checking for available updates Nov 25 04:02:22 Tower Docker Auto Update: Installing Updates for Influxdb2 telegraf bazarr binhex-plexpass Grafana GrafanaLoki GrafanaPromtail habridge jackett mariadb MKVToolNix mysql nextcloud nzbget nzbhydra2 ombi Organizr radarr Stash tautulli unifi-controller Dozzle Nov 25 04:02:28 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup.php update Nov 25 04:05:25 Tower Docker Auto Update: Community Applications Docker Autoupdate finished Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered blocking state Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered disabled state Nov 25 04:05:26 Tower kernel: device veth103203f entered promiscuous mode Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered blocking state Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered forwarding state Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered disabled state Nov 25 04:05:26 Tower kernel: eth0: renamed from veth3529a94 Nov 25 04:05:26 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth103203f: link becomes ready Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered blocking state Nov 25 04:05:26 Tower kernel: docker0: port 1(veth103203f) entered forwarding state Nov 25 04:05:26 Tower kernel: docker0: port 2(vethcbdc85a) entered blocking state Nov 25 04:05:26 Tower kernel: docker0: port 2(vethcbdc85a) entered disabled state Nov 25 04:05:26 Tower kernel: device vethcbdc85a entered promiscuous mode Nov 25 04:05:26 Tower kernel: docker0: port 2(vethcbdc85a) entered blocking state Nov 25 04:05:26 Tower kernel: docker0: port 2(vethcbdc85a) entered forwarding state Nov 25 04:05:26 Tower kernel: eth0: renamed from vethf09dcf8 Nov 25 04:05:26 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethcbdc85a: link becomes ready Nov 25 04:05:26 Tower kernel: eth0: renamed from veth17417db Nov 25 04:05:26 Tower kernel: device br0 entered promiscuous mode Nov 25 04:05:26 Tower kernel: docker0: port 3(veth832e080) entered blocking state Nov 25 04:05:26 Tower kernel: docker0: port 3(veth832e080) entered disabled state Nov 25 04:05:26 Tower kernel: device veth832e080 entered promiscuous mode Nov 25 04:05:26 Tower kernel: docker0: port 3(veth832e080) entered blocking state Nov 25 04:05:26 Tower kernel: docker0: port 3(veth832e080) entered forwarding state Nov 25 04:05:27 Tower kernel: docker0: port 3(veth832e080) entered disabled state Nov 25 04:05:27 Tower kernel: eth0: renamed from veth6aad366 Nov 25 04:05:27 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth832e080: link becomes ready Nov 25 04:05:27 Tower kernel: docker0: port 3(veth832e080) entered blocking state Nov 25 04:05:27 Tower kernel: docker0: port 3(veth832e080) entered forwarding state Nov 25 04:05:27 Tower kernel: docker0: port 4(vethb25ad7c) entered blocking state Nov 25 04:05:27 Tower kernel: docker0: port 4(vethb25ad7c) entered disabled state Nov 25 04:05:27 Tower kernel: device vethb25ad7c entered promiscuous mode Nov 25 04:05:27 Tower kernel: docker0: port 4(vethb25ad7c) entered blocking state Nov 25 04:05:27 Tower kernel: docker0: port 4(vethb25ad7c) entered forwarding state Nov 25 04:05:27 Tower kernel: eth0: renamed from vetha8162fd Nov 25 04:05:27 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethb25ad7c: link becomes ready Nov 25 04:05:27 Tower kernel: docker0: port 5(veth30aa97a) entered blocking state Nov 25 04:05:27 Tower kernel: docker0: port 5(veth30aa97a) entered disabled state Nov 25 04:05:27 Tower kernel: device veth30aa97a entered promiscuous mode Nov 25 04:05:27 Tower kernel: docker0: port 5(veth30aa97a) entered blocking state Nov 25 04:05:27 Tower kernel: docker0: port 5(veth30aa97a) entered forwarding state Nov 25 04:05:27 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth103203f.IPv6 with address fe80::5ceb:7bff:fee3:33dd. Nov 25 04:05:27 Tower avahi-daemon[11847]: New relevant interface veth103203f.IPv6 for mDNS. Nov 25 04:05:27 Tower avahi-daemon[11847]: Registering new address record for fe80::5ceb:7bff:fee3:33dd on veth103203f.*. Nov 25 04:05:27 Tower kernel: eth0: renamed from veth5e50f06 Nov 25 04:05:27 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth30aa97a: link becomes ready Nov 25 04:05:27 Tower kernel: docker0: port 6(vethb48c0f4) entered blocking state Nov 25 04:05:27 Tower kernel: docker0: port 6(vethb48c0f4) entered disabled state Nov 25 04:05:27 Tower kernel: device vethb48c0f4 entered promiscuous mode Nov 25 04:05:27 Tower kernel: docker0: port 6(vethb48c0f4) entered blocking state Nov 25 04:05:27 Tower kernel: docker0: port 6(vethb48c0f4) entered forwarding state Nov 25 04:05:27 Tower kernel: eth0: renamed from veth0a141e0 Nov 25 04:05:27 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethb48c0f4: link becomes ready Nov 25 04:05:27 Tower kernel: docker0: port 7(vethf45d661) entered blocking state Nov 25 04:05:27 Tower kernel: docker0: port 7(vethf45d661) entered disabled state Nov 25 04:05:27 Tower kernel: device vethf45d661 entered promiscuous mode Nov 25 04:05:27 Tower kernel: docker0: port 7(vethf45d661) entered blocking state Nov 25 04:05:27 Tower kernel: docker0: port 7(vethf45d661) entered forwarding state Nov 25 04:05:28 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethcbdc85a.IPv6 with address fe80::b425:3dff:fef3:4d5f. Nov 25 04:05:28 Tower avahi-daemon[11847]: New relevant interface vethcbdc85a.IPv6 for mDNS. Nov 25 04:05:28 Tower avahi-daemon[11847]: Registering new address record for fe80::b425:3dff:fef3:4d5f on vethcbdc85a.*. Nov 25 04:05:28 Tower kernel: docker0: port 7(vethf45d661) entered disabled state Nov 25 04:05:28 Tower kernel: eth0: renamed from veth2a444b7 Nov 25 04:05:28 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethf45d661: link becomes ready Nov 25 04:05:28 Tower kernel: docker0: port 7(vethf45d661) entered blocking state Nov 25 04:05:28 Tower kernel: docker0: port 7(vethf45d661) entered forwarding state Nov 25 04:05:28 Tower kernel: docker0: port 8(vethd7d540c) entered blocking state Nov 25 04:05:28 Tower kernel: docker0: port 8(vethd7d540c) entered disabled state Nov 25 04:05:28 Tower kernel: device vethd7d540c entered promiscuous mode Nov 25 04:05:28 Tower kernel: docker0: port 8(vethd7d540c) entered blocking state Nov 25 04:05:28 Tower kernel: docker0: port 8(vethd7d540c) entered forwarding state Nov 25 04:05:28 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth832e080.IPv6 with address fe80::d09e:f5ff:fef3:def4. Nov 25 04:05:28 Tower avahi-daemon[11847]: New relevant interface veth832e080.IPv6 for mDNS. Nov 25 04:05:28 Tower avahi-daemon[11847]: Registering new address record for fe80::d09e:f5ff:fef3:def4 on veth832e080.*. Nov 25 04:05:28 Tower kernel: eth0: renamed from veth09f1eb6 Nov 25 04:05:28 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethd7d540c: link becomes ready Nov 25 04:05:28 Tower kernel: docker0: port 9(veth8c1d7b3) entered blocking state Nov 25 04:05:28 Tower kernel: docker0: port 9(veth8c1d7b3) entered disabled state Nov 25 04:05:28 Tower kernel: device veth8c1d7b3 entered promiscuous mode Nov 25 04:05:28 Tower kernel: docker0: port 9(veth8c1d7b3) entered blocking state Nov 25 04:05:28 Tower kernel: docker0: port 9(veth8c1d7b3) entered forwarding state Nov 25 04:05:28 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth30aa97a.IPv6 with address fe80::a8ae:c2ff:fe71:b335. Nov 25 04:05:28 Tower avahi-daemon[11847]: New relevant interface veth30aa97a.IPv6 for mDNS. Nov 25 04:05:28 Tower avahi-daemon[11847]: Registering new address record for fe80::a8ae:c2ff:fe71:b335 on veth30aa97a.*. Nov 25 04:05:28 Tower kernel: eth0: renamed from vethf1a6312 Nov 25 04:05:28 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethb25ad7c.IPv6 with address fe80::207d:d7ff:fe5b:7669. Nov 25 04:05:28 Tower avahi-daemon[11847]: New relevant interface vethb25ad7c.IPv6 for mDNS. Nov 25 04:05:28 Tower avahi-daemon[11847]: Registering new address record for fe80::207d:d7ff:fe5b:7669 on vethb25ad7c.*. Nov 25 04:05:28 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth8c1d7b3: link becomes ready Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered blocking state Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered disabled state Nov 25 04:05:29 Tower kernel: device veth5d49058 entered promiscuous mode Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered blocking state Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered forwarding state Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered disabled state Nov 25 04:05:29 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethb48c0f4.IPv6 with address fe80::1c30:2bff:fe19:c075. Nov 25 04:05:29 Tower avahi-daemon[11847]: New relevant interface vethb48c0f4.IPv6 for mDNS. Nov 25 04:05:29 Tower avahi-daemon[11847]: Registering new address record for fe80::1c30:2bff:fe19:c075 on vethb48c0f4.*. Nov 25 04:05:29 Tower kernel: eth0: renamed from vethbead3ee Nov 25 04:05:29 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth5d49058: link becomes ready Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered blocking state Nov 25 04:05:29 Tower kernel: docker0: port 10(veth5d49058) entered forwarding state Nov 25 04:05:29 Tower kernel: docker0: port 11(vethe7a88df) entered blocking state Nov 25 04:05:29 Tower kernel: docker0: port 11(vethe7a88df) entered disabled state Nov 25 04:05:29 Tower kernel: device vethe7a88df entered promiscuous mode Nov 25 04:05:29 Tower kernel: docker0: port 11(vethe7a88df) entered blocking state Nov 25 04:05:29 Tower kernel: docker0: port 11(vethe7a88df) entered forwarding state Nov 25 04:05:29 Tower kernel: eth0: renamed from veth0de55cc Nov 25 04:05:29 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethe7a88df: link becomes ready Nov 25 04:05:29 Tower kernel: docker0: port 12(veth55df4e5) entered blocking state Nov 25 04:05:29 Tower kernel: docker0: port 12(veth55df4e5) entered disabled state Nov 25 04:05:29 Tower kernel: device veth55df4e5 entered promiscuous mode Nov 25 04:05:29 Tower kernel: docker0: port 12(veth55df4e5) entered blocking state Nov 25 04:05:29 Tower kernel: docker0: port 12(veth55df4e5) entered forwarding state Nov 25 04:05:29 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethf45d661.IPv6 with address fe80::641c:e0ff:fe7f:a222. Nov 25 04:05:29 Tower avahi-daemon[11847]: New relevant interface vethf45d661.IPv6 for mDNS. Nov 25 04:05:29 Tower avahi-daemon[11847]: Registering new address record for fe80::641c:e0ff:fe7f:a222 on vethf45d661.*. Nov 25 04:05:29 Tower kernel: eth0: renamed from vethc411b47 Nov 25 04:05:29 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth55df4e5: link becomes ready Nov 25 04:05:30 Tower kernel: eth0: renamed from veth1d2c254 Nov 25 04:05:30 Tower kernel: docker0: port 13(veth9ccc506) entered blocking state Nov 25 04:05:30 Tower kernel: docker0: port 13(veth9ccc506) entered disabled state Nov 25 04:05:30 Tower kernel: device veth9ccc506 entered promiscuous mode Nov 25 04:05:30 Tower kernel: docker0: port 13(veth9ccc506) entered blocking state Nov 25 04:05:30 Tower kernel: docker0: port 13(veth9ccc506) entered forwarding state Nov 25 04:05:30 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethd7d540c.IPv6 with address fe80::1c74:5ff:fe1c:b306. Nov 25 04:05:30 Tower avahi-daemon[11847]: New relevant interface vethd7d540c.IPv6 for mDNS. Nov 25 04:05:30 Tower avahi-daemon[11847]: Registering new address record for fe80::1c74:5ff:fe1c:b306 on vethd7d540c.*. Nov 25 04:05:30 Tower kernel: eth0: renamed from vethe5c9383 Nov 25 04:05:30 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth9ccc506: link becomes ready Nov 25 04:05:30 Tower kernel: docker0: port 14(vethe3bc049) entered blocking state Nov 25 04:05:30 Tower kernel: docker0: port 14(vethe3bc049) entered disabled state Nov 25 04:05:30 Tower kernel: device vethe3bc049 entered promiscuous mode Nov 25 04:05:30 Tower kernel: docker0: port 14(vethe3bc049) entered blocking state Nov 25 04:05:30 Tower kernel: docker0: port 14(vethe3bc049) entered forwarding state Nov 25 04:05:30 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth5d49058.IPv6 with address fe80::3805:4bff:fe40:8f4d. Nov 25 04:05:30 Tower avahi-daemon[11847]: New relevant interface veth5d49058.IPv6 for mDNS. Nov 25 04:05:30 Tower avahi-daemon[11847]: Registering new address record for fe80::3805:4bff:fe40:8f4d on veth5d49058.*. Nov 25 04:05:30 Tower kernel: eth0: renamed from veth515d0e6 Nov 25 04:05:30 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethe3bc049: link becomes ready Nov 25 04:05:30 Tower kernel: docker0: port 15(veth035980e) entered blocking state Nov 25 04:05:30 Tower kernel: docker0: port 15(veth035980e) entered disabled state Nov 25 04:05:30 Tower kernel: device veth035980e entered promiscuous mode Nov 25 04:05:30 Tower kernel: docker0: port 15(veth035980e) entered blocking state Nov 25 04:05:30 Tower kernel: docker0: port 15(veth035980e) entered forwarding state Nov 25 04:05:30 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth8c1d7b3.IPv6 with address fe80::45c:42ff:fe29:49e. Nov 25 04:05:30 Tower avahi-daemon[11847]: New relevant interface veth8c1d7b3.IPv6 for mDNS. Nov 25 04:05:30 Tower avahi-daemon[11847]: Registering new address record for fe80::45c:42ff:fe29:49e on veth8c1d7b3.*. Nov 25 04:05:30 Tower kernel: eth0: renamed from veth6afc9d2 Nov 25 04:05:30 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth035980e: link becomes ready Nov 25 04:05:30 Tower kernel: docker0: port 16(vethaa3fff4) entered blocking state Nov 25 04:05:30 Tower kernel: docker0: port 16(vethaa3fff4) entered disabled state Nov 25 04:05:30 Tower kernel: device vethaa3fff4 entered promiscuous mode Nov 25 04:05:30 Tower kernel: docker0: port 16(vethaa3fff4) entered blocking state Nov 25 04:05:30 Tower kernel: docker0: port 16(vethaa3fff4) entered forwarding state Nov 25 04:05:31 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethe7a88df.IPv6 with address fe80::8456:99ff:fe30:d08b. Nov 25 04:05:31 Tower avahi-daemon[11847]: New relevant interface vethe7a88df.IPv6 for mDNS. Nov 25 04:05:31 Tower avahi-daemon[11847]: Registering new address record for fe80::8456:99ff:fe30:d08b on vethe7a88df.*. Nov 25 04:05:31 Tower kernel: docker0: port 16(vethaa3fff4) entered disabled state Nov 25 04:05:31 Tower kernel: eth0: renamed from veth07b4850 Nov 25 04:05:31 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethaa3fff4: link becomes ready Nov 25 04:05:31 Tower kernel: docker0: port 16(vethaa3fff4) entered blocking state Nov 25 04:05:31 Tower kernel: docker0: port 16(vethaa3fff4) entered forwarding state Nov 25 04:05:31 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth55df4e5.IPv6 with address fe80::c09d:a6ff:fead:b0b5. Nov 25 04:05:31 Tower avahi-daemon[11847]: New relevant interface veth55df4e5.IPv6 for mDNS. Nov 25 04:05:31 Tower avahi-daemon[11847]: Registering new address record for fe80::c09d:a6ff:fead:b0b5 on veth55df4e5.*. Nov 25 04:05:31 Tower kernel: docker0: port 17(vethc072768) entered blocking state Nov 25 04:05:31 Tower kernel: docker0: port 17(vethc072768) entered disabled state Nov 25 04:05:31 Tower kernel: device vethc072768 entered promiscuous mode Nov 25 04:05:31 Tower kernel: docker0: port 17(vethc072768) entered blocking state Nov 25 04:05:31 Tower kernel: docker0: port 17(vethc072768) entered forwarding state Nov 25 04:05:32 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface vethe3bc049.IPv6 with address fe80::a024:d7ff:febf:7d89. Nov 25 04:05:32 Tower avahi-daemon[11847]: New relevant interface vethe3bc049.IPv6 for mDNS. Nov 25 04:05:32 Tower avahi-daemon[11847]: Registering new address record for fe80::a024:d7ff:febf:7d89 on vethe3bc049.*. Nov 25 04:05:32 Tower kernel: eth0: renamed from veth857beb6 Nov 25 04:05:32 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethc072768: link becomes ready Nov 25 04:05:32 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth035980e.IPv6 with address fe80::6c73:bfff:fead:cb03. Nov 25 04:05:32 Tower avahi-daemon[11847]: New relevant interface veth035980e.IPv6 for mDNS. Nov 25 04:05:32 Tower avahi-daemon[11847]: Registering new address record for fe80::6c73:bfff:fead:cb03 on veth035980e.*. Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered blocking state Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered disabled state Nov 25 04:05:32 Tower kernel: device veth10c5657 entered promiscuous mode Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered blocking state Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered forwarding state Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered disabled state Nov 25 04:05:32 Tower avahi-daemon[11847]: Joining mDNS multicast group on interface veth9ccc506.IPv6 with address fe80::8d8:d5ff:fe40:80e. Nov 25 04:05:32 Tower avahi-daemon[11847]: New relevant interface veth9ccc506.IPv6 for mDNS. Nov 25 04:05:32 Tower avahi-daemon[11847]: Registering new address record for fe80::8d8:d5ff:fe40:80e on veth9ccc506.*. Nov 25 04:05:32 Tower kernel: eth0: renamed from vethe668aab Nov 25 04:05:32 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth10c5657: link becomes ready Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered blocking state Nov 25 04:05:32 Tower kernel: docker0: port 18(veth10c5657) entered forwarding state Nov 25 04:05:32 Tower kernel: docker0: port 19(vethbb00449) entered blocking state Nov 25 04:05:32 Tower kernel: docker0: port 19(vethbb00449) entered disabled state Nov 25 04:05:32 Tower kernel: device vethbb00449 entered promiscuous mode Nov 25 04:05:32 Tower kernel: docker0: port 19(vethbb00449) entered blocking state Nov 25 04:05:32 Tower kernel: docker0: port 19(vethbb00449) entered forwarding state Nov 25 04:05:32 Tower kernel: eth0: renamed from vethf80ec4d Nov 25 04:05:32 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethbb00449: link becomes ready Nov 25 04:05:32 Tower CA Backup/Restore: ####################### Nov 25 04:05:32 Tower CA Backup/Restore: appData Backup complete Nov 25 04:05:32 Tower CA Backup/Restore: ####################### -
So my monthly backups run on the 25th, and like clockwork I've recived a Pushover notification that it has completed the backup.
I've suffered data loss, and I have no idea what happend. My influxdb appdata folder is suddenly completely empty (no settings, no database). I figured I'd just restore the latest backup, but they apparently haven't been stored for the past couple of months..
Anyone got any idea what could have happend? Both with the influxdb and with this plugin. My settings:
-
I've removed diagnostics from OP. I think I found the problem myself by scouring the logs. There were indications it was caused by "mongod" which afaik is probably the db used by unifi-controller docker. It makes sense cause that docker has been plagued with problems. Lately it suddenly pumps out insane amounts of data cause of some bug.
I've tried reinstalling the entire container now and just restoring config from a backup. Hopefully that can help, but I'll keep an eye out.
Is there an easy way I can set a new "starting point" for fix common problems? I.e. I'd like it to notify me about new oom-events, but not the ones I've already seen here.
-
Hi,
Every time fix common problems run I'm getting errors that it detects OOM-situations on my server. However I monitor the memory usage, and I'm not seeing anywhere close to full there. Usually hovering around 40%.
Is this just a bug in reporting, or is there something I'm not seeing? How can I identify the culprit?
Diagnostics attached.
-
Seems that my Windows VM was logged out, and that prevented a normal shutdown for the plugin. I've made it so it stays logged in to the user account, and it performs well now. Thanks
-
Hi,
I'm trying to set up this plugin to backup a VM that is running. I.e. it needs to be shut off before the backup.
The plugin logs that it tries to shut it off, but it's not working. I've tested and the VM can ble cleanly shut down with "Stop" through the WebUI, so theres nothing preventing the VM from being shut off.
Theres also nothing in the syslog indicating that the VM has gotten a shutdown-command, so I'm pretty sure this is not working from the plugin.
Any pointers? I obviously don't want to enable force shutdown/kill.
Thanks!
-
2 hours ago, JorgeB said:
I don't know what happened to that device but there's no valid filesystem there, so don't see how to recover.
Thats a shame. I've been working on my backup, and it's nowhere near as good/fresh/complete as it should have been.
Is there any reason I shouldn't trust this drive from your point of view?
Thanks again
-
2 hours ago, JorgeB said:
Replace X with correct letter.
Thanks for getting back to me. Unfortunately it still doesn't find a file system there
root@Tower:~# btrfs-select-super -s 1 /dev/sdn1 No valid Btrfs found on /dev/sdn1 Open ctree failed -
I suspect the drive didn't get re-formatted correctly when I made it into cache_vms, and that's why btrfs commands are not working.
I hope it's okay to try and tag @JorgeB here cause I think he or she is the person for the job. Thanks a lot
root@Tower:~# fdisk /dev/sdn -l Disk /dev/sdn: 223.57 GiB, 240057409536 bytes, 468862128 sectors Disk model: KINGSTON SV300S3 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdn1 2048 468862127 468860080 223.6G 83 Linuxroot@Tower:~# file -sL /dev/sdn /dev/sdn: DOS/MBR boot sector; partition 1 : ID=0x83, start-CHS (0x0,0,0), end-CHS (0x0,0,0), startsector 2048, 468860080 sectors, extended partition table (last)parted command is not available on unraid it seems.
-
I've also tried restoring backup superblock as outlined here, but got the same results as OP in that thread.
-
Hi,
I'm upgrading my server, and wanted to run my VMs from a newly created cache pool. I moved my vdisks to the array, formatted the drive as a cache-pool (btrfs) with a single drive, and moved the vdisks back. I then started the VM and checked everything, it was working well.
Now I had to do a reboot since I'd filled up my log-vdisk from running the mover (moved plex-directory with loads of files).
After rebooting the new cache_vms is showing as unmountable. I've tried step 1 and 2 from here, but it didn't work.
root@Tower:/# mount -o usebackuproot,ro /dev/sdn1 /x mount: /x: wrong fs type, bad option, bad superblock on /dev/sdn1, missing codepage or helper program, or other error.root@Tower:/mnt/disk8# btrfs restore -v /dev/sdn1 /mnt/disk8/restore No valid Btrfs found on /dev/sdn1 Could not open root, trying backup super No valid Btrfs found on /dev/sdn1 Could not open root, trying backup super ERROR: superblock bytenr 274877906944 is larger than device size 240056360960Now is there any chance of getting my images back? One of the VMs runs my home automations and is kinda critical. I've got a windows backup of the important files, but I was hoping to avoid having to set up a new VM and restoring the data.
Diagnostics attached
Thanks a bunch!
-
Hi,
I wanted to ask just to be sure before doing something very stupid..
I've upgraded my server and with it comes a new nvme drive that I want to use for Dockers. I've created the new cache called cache_nvme, and set Shares "appdata" and "system" to prefer the new cache_nvme.
The files are however still left on the old cache, and I've tried to find the "correct" way to move it. Should I:
- Set the shares to Yes: Cache_nvme
- Invoke the mover
- Set the shares to Prefer: cache_nvme
- Invoke the mover
Or is there a better way? I guess I could disable Docker and move with terminal from /mnt/cache/appdata/ to /mnt/cache_nvme/appdata, but that kind of sounds more risky to me.
Thanks!
-
Hey guys,
I'm about to upgrade my Unraid server, and wanted to check in with you to see if there is anything I'm forgetting or should change before taking the leap.
I'm currently on 6.8.2 running on an old Proliant ML350 G6 - 2x Xeon 5650x, 40GB ECC RAM. Drives are attached via a SAS-expander through an LSI (9207-8e I believe) controller. I'm running about 25 Dockers and 2-4 VMs. I've got a 1TB SSD as the main Cache, a 250GB SSD through Unassigned drives for my VMs and a 1TB spinner throught Unassigned drives for temporary downloads (for the extraction).
Now I want to upgrade to something a bit more lightweight (power/noise-wise) while keeping most of the oomph. I'm also getting a NVME drive for database performance.
Here is my hardware purchase list. I've got a chassis and a PSU. It's a downgrade on the RAM-capacity, but I've got room to expand if need be. I'm choosing previous generation Ryzen as it's more affordable and accessible than the newer 5600X counterpart with roughly the same performance.
- Ryzen 7 3700X
- 2x 16GB Corsair Vengeance RGB PRO SL DDR4-3600 DC C18
-
GIGABYTE B450 AORUS PRO
-
WD Black SN850 PCIe 4.0 NVMe M.2 - 500GB
I plan on upgrading to 6.9 and make use of the new cache pools. This is the plan:
- NVMe drive for Dockers, including the various database applications (InfluxDB for metrics/Grafana, MariaDB for NextCloud, MySQL for various applications/development). Shares using this drive will prefer cache
- Existing 1TB SSD as my "main" cache which will recieve writes such as downloads and file transfers. Shares that use this will be set up to move to array
- Existing 250GB SSD will continue to hold my VMs
Now as far as I can tell I should be able to build the new server, move the SAS-controller and USB-drive and it should boot into Unraid. I'll then have to set up the new cache pools and be good to go, right?
I'd love some input if you've got some. Thanks!
-
I ended up shutting the system down from vacation. When I came back I re-seated all cables to SAS-expanders and booted again. Parity was marked as invalid.
I did a read-check of the array which went without errors. Then I stopped the array, unassigned the parity drives, started the array, stopped the array, assigned parity drives again. It re-built both parity drives without errors, and is seemingly running well now.
I'll pay attention to the RAM usage going forward. Thanks.
-
1
-
-
Diagnostics attached, thanks
EDIT: Diagnostics removed.
-
Hi guys,
I'm on vacation but got some concerning notifications from unRAID l night. Both my parity drives had been disabled within the same minute, I've got errors all over and a warning on my cache drive.
I'm afraid to stop the array or reboot.
Any advice?
Attached screenshot
-
On 5/13/2021 at 12:56 PM, twistedsanity said:
Sorry, I may have missed something completely earlier in discussions but mine also had this issue as it looks like dockerhub linuxserver.io shows version 6.1.71 attached to the tag 'latest' which it isn't (its a release from a month or so ago) and mine is trying to downgrade to it as its thinking it is a new release.
*** I fixed this (temporarily until linuxserver.io fix the tags) by changing out the repository field to "linuxserver/unifi-controller:version-6.2.23" this then reinstalled the 6.2.23 version and the container came up. ***
Note: once fixed by linuxserver you will need to revert the repository field or you won't get updates.
I don't know why, but this is not working for me. The server.log is spammed with various warnings about mongod not being shut down correctly and needs repairing.
Mongod.log on the other hand has other messages thats equally cryptic to me unfortunately.. Seems to still be a version mismatch:
Fatal assertion 28579 UnsupportedFormat: Unable to find metadata for table:index-1--7693998512115095491 Index: {name: site_id_1, ns: ace.account} - version too new for this mongod. See http://dochub.mongodb.org/core/3.4-index-downgrade for detailed instructions on how to handle this error. at src/mongo/db/storage/wiredtiger/wiredtiger_index.cpp 268 -
This is with a Debian bare-metal VPS without GUI so I dont think thats an option unfortunately. I'm trying to contact my influxdb-server using this command:
curl -G http://MY-IP:8086/query -u username:password --data-urlencode "q=SHOW DATABASES"The same command works when trying from another computer on the same network, then by using the local IP. I'm obviously using my global IP when trying from VPS. Same username and password works locally.
EDIT: Got it! It was my port forwarding that was off, damn Unifi changing the entire UI between each time I edit settings..
-
Anyone that can help me get access to my influxdb remotely? I want to be able to add some metrics from my VPS to InfluxDB, but I'm struggling with connecting.
I've forwarded port 8086 in my firewall to my Unraid server which is set up with the same port. I don't understand but I still cant get to it. Is there anything I need to change in the influxdb configuration files?
-
I'm having an issue with this where the container keeps writing to the docker.img, is there anything I can do to change the path? Or the retainment policy for logs?
Currently sitting at close to 9gb for this image which is just too damn high
EDIT: So here's what you do.. Change local.conf.yaml in appdata/loki/conf FROM
table_manager: retention_deletes_enabled: false retention_period: 0sto this:
table_manager: retention_deletes_enabled: true retention_period: 24hNow it will rotate logs out of retention after 24 hours. You can change the period to whatever you like ofcourse.
The container has to be deleted and re-made it seems for the old data to be deleted.
[Support] for atribe's repo Docker images
in Docker Containers
Posted
I'm not, sorry. I set it up again and forgot about this problem. It does mean it's kinda likely to happen again though..