54lzy

Believe I did. Also I believe if you try and start a docker compose stack where the container name is the same as a created but stopped container, it will give an error.

I have a container which I recently transitioned to being managed/run via docker compose (specifically, a dockhand client running on another host) rather than the Unraid Community Apps template. Whenever the container is stopped/started, for example for app data backup, or for auto update applications (side note: forgot I had this and turned off for all docker containers) it restarts an older version of the container: namely a different container build, not routing the container through gluetun, etc. I deleted the template in /boot/config/plugins/dockerMan/templates-user/ and I am hoping this fixes it. I had already disabled the container from being backed up but maybe because gluetun was backed up via app data backup, it still stopped and started the container in question. Basically I want to make sure if Unraid/the plugin ever stops this container, the newer version managed by compose (with all its variables, network, etc) is setup. Any advice? TLDR: Migrated qBittorrent from Unraid Community Apps to Docker Compose (managed by Dockhand on a separate host). Unraid's Appdata Backup plugin keeps restarting the old version of the container.

Thanks this is right. I hope maybe they will get rid of that error considering the trailing "/" is needed. I am all set now (had some issues whitelisting usernames but emails worked).

How did you fix the fact that the issuer URL will not allow a trailing slash, but then Authentik will not work unless you have the trailing slash? It sounds like you overcame it, but how?

I have the container up and running well. One nit I am trying to resolve: I use cross-seed. I have a post-download command to run a search, however, I need to specify container IP, hostname does not work. Both containers (qbit and cross-seed) are on the same custom network. Other containers on the same network can reach cross-seed with its host name. I think this must have something to do with DNS. Is there a way to easily resolve this in a manner that is a best practice?

I solved this and it was user error. In all my troubleshooting of the Wireguard config, I added allowed IPs of 0.0.0.0/0 to multiple devices connected to the network on the Unraid page. I think what this did was try to send traffic on the wireguard network to those devices. Once I deleted this (after reading the help text on the wireguard page which helped immensely), the issue was solved. Leaving this up to help others.

I am trying to setup a Wireguard network. The subnet is 10.253.0.0/24. The reason I want to do this is so I can remotely access my Unraid server. I can try Tailscale as a fallback but trying to do everything myself on Wireguard to avoid third parties. I am trying to setup a Linux LXC running adguard to the Wireguard network. I am having issues where I will be able to get a handshake but either not be able to ping any my Unraid server (which has the ip of 10.253.0.1 on the wireguard server) OR I will be able to but won't have internet access. For example right now I have setup as "remote tunneled access" and can ping 10.253.0.1 but not 1.1.1.1. When I try to ping I get the following error: PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. From 10.253.0.1 icmp_seq=1 Destination Host Unreachable My config is as follows: [Interface] #adguard-lxc PrivateKey=[redacted] Address=10.253.0.9/32 DNS=1.1.1.1 [Peer] #unraidwg PersistentKeepalive=25 PublicKey=[] Endpoint=wg.redacted.com:51820 AllowedIPs=0.0.0.0/0 I have the following static route setup on my unifi router: I appreciate you for taking the time to look at this. Hopefully I can get this resolved. What is bothering me is I feel like I had this working last night at some point and then it stopped working. I have cycled through so many configs (server access where I cannot ping 10.253.0.1, remote lan access, remote tunneled, etc) trying to get this to work. Ultimately the purpose of this container is to run adguard as a DNS for the wireguard network and wildcard redirect to my domain.

I updated my docker settings to use ipvlan instead of macvlan. My server froze up last night around 312AM. The server is freezing up every 9 or 10 days (i.e. not that frequently). I have docker auto update scheduled to run at 3am every night. Is there any way to have a better log? Isnt it true that if the server freezes up you will lose the log that is kept in ram. When it was frozen, I couldn't ssh in or login locally either.

Is this the error I keep getting? I think I had switched to ipvlan but then the latest release fixed the problem so I think I switched back.

I was trying to connect to my VM (Debian install with no GUI) using the Unraid dashboard's VM page. When I tried to log in, I could not type anything. It seemed like the VM was frozen because remoting in did not work either. I tried restarting and it did not seem to be working, so I hit stop instead. Then I noticed the entire server locked up. I was able to login locally using a keyboard, but when I logged in I could not type. So I started to hold the power button on the server. I noticed it said server is going down, so I gave it a couple minutes. It did not shut down so I did a hard power off. Here is the log after immediately rebooting, I am wondering if it is helpful (bottom half always happened and I am not sure why, but maybe the top half can help someone smarter than me decipher what happened): Oct 31 19:47:09 Tower kernel: RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff88815e2f5e00 Oct 31 19:47:09 Tower kernel: RBP: 0000000000000001 R08: e40b881763908dfc R09: 12a473daccea1235 Oct 31 19:47:09 Tower kernel: R10: ece7970bfee65b62 R11: ffffc900081137b0 R12: ffffffff82a11d00 Oct 31 19:47:09 Tower kernel: R13: 0000000000029ede R14: ffff888129f5a000 R15: 0000000000000000 Oct 31 19:47:09 Tower kernel: FS: 00001500f26ff7c0(0000) GS:ffff8888904c0000(0000) knlGS:0000000000000000 Oct 31 19:47:09 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 31 19:47:09 Tower kernel: CR2: 00003e306c7b0000 CR3: 000000015a638000 CR4: 0000000000750ee0 Oct 31 19:47:09 Tower kernel: PKRU: 55555558 Oct 31 19:47:09 Tower kernel: Call Trace: Oct 31 19:47:09 Tower kernel: <TASK> Oct 31 19:47:09 Tower kernel: ? __warn+0xab/0x122 Oct 31 19:47:09 Tower kernel: ? report_bug+0x109/0x17e Oct 31 19:47:09 Tower kernel: ? __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Oct 31 19:47:09 Tower kernel: ? handle_bug+0x41/0x6f Oct 31 19:47:09 Tower kernel: ? exc_invalid_op+0x13/0x60 Oct 31 19:47:09 Tower kernel: ? asm_exc_invalid_op+0x16/0x20 Oct 31 19:47:09 Tower kernel: ? __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Oct 31 19:47:09 Tower kernel: ? __nf_conntrack_confirm+0x9e/0x2b0 [nf_conntrack] Oct 31 19:47:09 Tower kernel: ? nf_nat_inet_fn+0xc0/0x1a8 [nf_nat] Oct 31 19:47:09 Tower kernel: nf_conntrack_confirm+0x25/0x54 [nf_conntrack] Oct 31 19:47:09 Tower kernel: nf_hook_slow+0x3a/0x96 Oct 31 19:47:09 Tower kernel: ? ip_protocol_deliver_rcu+0x164/0x164 Oct 31 19:47:09 Tower kernel: NF_HOOK.constprop.0+0x79/0xd9 Oct 31 19:47:09 Tower kernel: ? ip_protocol_deliver_rcu+0x164/0x164 Oct 31 19:47:09 Tower kernel: ip_sabotage_in+0x4f/0x60 [br_netfilter] Oct 31 19:47:09 Tower kernel: nf_hook_slow+0x3a/0x96 Oct 31 19:47:09 Tower kernel: ? ip_rcv_finish_core.constprop.0+0x3e8/0x3e8 Oct 31 19:47:09 Tower kernel: NF_HOOK.constprop.0+0x79/0xd9 Oct 31 19:47:09 Tower kernel: ? ip_rcv_finish_core.constprop.0+0x3e8/0x3e8 Oct 31 19:47:09 Tower kernel: __netif_receive_skb_one_core+0x77/0x9c Oct 31 19:47:09 Tower kernel: netif_receive_skb+0xbf/0x127 Oct 31 19:47:09 Tower kernel: br_handle_frame_finish+0x438/0x472 [bridge] Oct 31 19:47:09 Tower kernel: ? br_pass_frame_up+0xdd/0xdd [bridge] Oct 31 19:47:09 Tower kernel: br_nf_hook_thresh+0xe2/0x109 [br_netfilter] Oct 31 19:47:09 Tower kernel: ? br_pass_frame_up+0xdd/0xdd [bridge] Oct 31 19:47:09 Tower kernel: br_nf_pre_routing_finish+0x2c1/0x2ec [br_netfilter] Oct 31 19:47:09 Tower kernel: ? br_pass_frame_up+0xdd/0xdd [bridge] Oct 31 19:47:09 Tower kernel: ? NF_HOOK.isra.0+0xe4/0x140 [br_netfilter] Oct 31 19:47:09 Tower kernel: ? br_nf_hook_thresh+0x109/0x109 [br_netfilter] Oct 31 19:47:09 Tower kernel: br_nf_pre_routing+0x236/0x24a [br_netfilter] Oct 31 19:47:09 Tower kernel: ? br_nf_hook_thresh+0x109/0x109 [br_netfilter] Oct 31 19:47:09 Tower kernel: br_handle_frame+0x277/0x2e0 [bridge] Oct 31 19:47:09 Tower kernel: ? br_pass_frame_up+0xdd/0xdd [bridge] Oct 31 19:47:09 Tower kernel: __netif_receive_skb_core.constprop.0+0x4fa/0x6e9 Oct 31 19:47:09 Tower kernel: ? __udp4_lib_lookup+0x2db/0x318 Oct 31 19:47:09 Tower kernel: ? __skb_checksum+0x5c/0x283 Oct 31 19:47:09 Tower kernel: __netif_receive_skb_list_core+0x8a/0x11e Oct 31 19:47:09 Tower kernel: netif_receive_skb_list_internal+0x1d2/0x20b Oct 31 19:47:09 Tower kernel: gro_normal_list+0x1d/0x3f Oct 31 19:47:09 Tower kernel: napi_complete_done+0x7b/0x11a Oct 31 19:47:09 Tower kernel: rtl8169_poll+0x3f0/0x414 [r8169] Oct 31 19:47:09 Tower kernel: __napi_poll.constprop.0+0x28/0x124 Oct 31 19:47:09 Tower kernel: net_rx_action+0x159/0x24f Oct 31 19:47:09 Tower kernel: __do_softirq+0x126/0x288 Oct 31 19:47:09 Tower kernel: __irq_exit_rcu+0x5e/0xb8 Oct 31 19:47:09 Tower kernel: common_interrupt+0x3b/0xc1 Oct 31 19:47:09 Tower kernel: asm_common_interrupt+0x22/0x40 Oct 31 19:47:09 Tower kernel: RIP: 0033:0x1500f279e272 Oct 31 19:47:09 Tower kernel: Code: 48 8b 82 70 08 00 00 48 39 f0 75 ac c7 05 4e 52 15 00 00 00 00 00 eb e1 41 54 55 53 48 89 fb 48 83 ec 10 80 3d 36 52 15 00 00 <0f> 84 f8 01 00 00 48 85 db 0f 88 fd 01 00 00 48 8d 43 17 31 ed 48 Oct 31 19:47:09 Tower kernel: RSP: 002b:00007ffd617d4920 EFLAGS: 00000202 Oct 31 19:47:09 Tower kernel: RAX: 0000000000000174 RBX: 0000000000000174 RCX: 0000000000000000 Oct 31 19:47:09 Tower kernel: RDX: 000035a5cb6eaae1 RSI: 000035a5cb6eaae1 RDI: 0000000000000174 Oct 31 19:47:09 Tower kernel: RBP: 00007ffd617d49f0 R08: 000035a5cb6eaae1 R09: f566a8ff5aa0a7a8 Oct 31 19:47:09 Tower kernel: R10: 0000000001b78ab2 R11: 00000ed37dd01689 R12: 00000000000000ba Oct 31 19:47:09 Tower kernel: R13: 0000000003361360 R14: 00000000000000ba R15: 000035a5cb6eaae1 Oct 31 19:47:09 Tower kernel: </TASK> Oct 31 19:47:09 Tower kernel: ---[ end trace 0000000000000000 ]--- Oct 31 19:47:09 Tower kernel: eth0: renamed from veth765f3db Oct 31 19:47:09 Tower emhttpd: shcmd (88): /usr/local/sbin/mount_image '/mnt/user/system/libvirt/libvirt.img' /etc/libvirt 1 Oct 31 19:47:09 Tower kernel: eth0: renamed from vethf016d9c Oct 31 19:47:09 Tower kernel: loop3: detected capacity change from 0 to 2097152 Oct 31 19:47:09 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth4cee523: link becomes ready Oct 31 19:47:09 Tower kernel: br-9eca54687cab: port 4(veth21adbd2) entered disabled state Oct 31 19:47:09 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth21adbd2: link becomes ready Oct 31 19:47:09 Tower kernel: br-9eca54687cab: port 4(veth21adbd2) entered blocking state Oct 31 19:47:09 Tower kernel: br-9eca54687cab: port 4(veth21adbd2) entered forwarding state Oct 31 19:47:09 Tower kernel: br-9eca54687cab: port 5(veth2ab0f40) entered blocking state Oct 31 19:47:09 Tower kernel: br-9eca54687cab: port 5(veth2ab0f40) entered disabled state Oct 31 19:47:09 Tower kernel: device veth2ab0f40 entered promiscuous mode Oct 31 19:47:09 Tower kernel: br-9eca54687cab: port 5(veth2ab0f40) entered blocking state Oct 31 19:47:09 Tower kernel: br-9eca54687cab: port 5(veth2ab0f40) entered forwarding state Oct 31 19:47:09 Tower kernel: BTRFS: device fsid b34feeee-3d5d-45b7-8c36-9c963e7b6116 devid 1 transid 274 /dev/loop3 scanned by mount (15822) Oct 31 19:47:09 Tower kernel: BTRFS info (device loop3): using crc32c (crc32c-intel) checksum algorithm Oct 31 19:47:09 Tower kernel: BTRFS info (device loop3): using free space tree Oct 31 19:47:09 Tower kernel: BTRFS info (device loop3): enabling ssd optimizations Oct 31 19:47:09 Tower root: Resize device id 1 (/dev/loop3) from 1.00GiB to max Oct 31 19:47:09 Tower emhttpd: shcmd (90): /etc/rc.d/rc.libvirt start Oct 31 19:47:09 Tower root: Starting virtlockd... Oct 31 19:47:09 Tower root: Starting virtlogd... Oct 31 19:47:09 Tower rc.docker: ActualServer: started succesfully! Oct 31 19:47:09 Tower root: Starting libvirtd... Oct 31 19:47:10 Tower kernel: tun: Universal TUN/TAP device driver, 1.6 Oct 31 19:47:10 Tower kernel: mdcmd (36): check correct Oct 31 19:47:10 Tower kernel: md: recovery thread: check P ... Oct 31 19:47:10 Tower kernel: eth0: renamed from veth4adb9cf Oct 31 19:47:10 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth2ab0f40: link becomes ready Oct 31 19:47:10 Tower kernel: eth0: renamed from veth9bc5cee Oct 31 19:47:10 Tower dnsmasq[16338]: started, version 2.89 cachesize 150 Oct 31 19:47:10 Tower dnsmasq[16338]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile Oct 31 19:47:10 Tower dnsmasq-dhcp[16338]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h Oct 31 19:47:10 Tower dnsmasq-dhcp[16338]: DHCP, sockets bound exclusively to interface virbr0 Oct 31 19:47:10 Tower dnsmasq[16338]: reading /etc/resolv.conf Oct 31 19:47:10 Tower dnsmasq[16338]: using nameserver 192.168.1.1#53 Oct 31 19:47:10 Tower rc.docker: AdGuard-Home: started succesfully! Oct 31 19:47:10 Tower dnsmasq[16338]: read /etc/hosts - 3 names Oct 31 19:47:10 Tower dnsmasq[16338]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 names Oct 31 19:47:10 Tower dnsmasq-dhcp[16338]: read /var/lib/libvirt/dnsmasq/default.hostsfile Oct 31 19:47:10 Tower kernel: r8169 0000:03:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM Oct 31 19:47:10 Tower kernel: mpt3sas 0000:04:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM Oct 31 19:47:10 Tower kernel: veth765f3db: renamed from eth0 Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 2(veth4cee523) entered disabled state Oct 31 19:47:10 Tower kernel: veth4adb9cf: renamed from eth0 Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 5(veth2ab0f40) entered disabled state Oct 31 19:47:10 Tower kernel: docker0: port 3(vetha80f820) entered blocking state Oct 31 19:47:10 Tower kernel: docker0: port 3(vetha80f820) entered disabled state Oct 31 19:47:10 Tower kernel: device vetha80f820 entered promiscuous mode Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 2(veth4cee523) entered disabled state Oct 31 19:47:10 Tower kernel: device veth4cee523 left promiscuous mode Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 2(veth4cee523) entered disabled state Oct 31 19:47:10 Tower kernel: docker0: port 3(vetha80f820) entered blocking state Oct 31 19:47:10 Tower kernel: docker0: port 3(vetha80f820) entered forwarding state Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 5(veth2ab0f40) entered disabled state Oct 31 19:47:10 Tower kernel: device veth2ab0f40 left promiscuous mode Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 5(veth2ab0f40) entered disabled state Oct 31 19:47:10 Tower kernel: docker0: port 3(vetha80f820) entered disabled state Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 2(veth586c350) entered blocking state Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 2(veth586c350) entered disabled state Oct 31 19:47:10 Tower kernel: device veth586c350 entered promiscuous mode Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 2(veth586c350) entered blocking state Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 2(veth586c350) entered forwarding state Oct 31 19:47:10 Tower kernel: eth0: renamed from veth9fc2ea0 Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 2(veth586c350) entered disabled state Oct 31 19:47:10 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vetha80f820: link becomes ready Oct 31 19:47:10 Tower kernel: docker0: port 3(vetha80f820) entered blocking state Oct 31 19:47:10 Tower kernel: docker0: port 3(vetha80f820) entered forwarding state Oct 31 19:47:10 Tower rc.docker: adguardhome-sync: started succesfully! Oct 31 19:47:10 Tower kernel: eth0: renamed from veth11ca83e Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 5(veth10fc8a4) entered blocking state Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 5(veth10fc8a4) entered disabled state Oct 31 19:47:10 Tower kernel: device veth10fc8a4 entered promiscuous mode Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 5(veth10fc8a4) entered blocking state Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 5(veth10fc8a4) entered forwarding state Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 5(veth10fc8a4) entered disabled state Oct 31 19:47:10 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth586c350: link becomes ready Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 2(veth586c350) entered blocking state Oct 31 19:47:10 Tower kernel: br-9eca54687cab: port 2(veth586c350) entered forwarding state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 6(veth78a57fc) entered blocking state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 6(veth78a57fc) entered disabled state Oct 31 19:47:11 Tower kernel: device veth78a57fc entered promiscuous mode Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 6(veth78a57fc) entered blocking state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 6(veth78a57fc) entered forwarding state Oct 31 19:47:11 Tower kernel: eth0: renamed from vethaea8349 Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 6(veth78a57fc) entered disabled state Oct 31 19:47:11 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth10fc8a4: link becomes ready Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 5(veth10fc8a4) entered blocking state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 5(veth10fc8a4) entered forwarding state Oct 31 19:47:11 Tower rc.docker: Apache-PHP: started succesfully! Oct 31 19:47:11 Tower kernel: eth0: renamed from veth98df2d0 Oct 31 19:47:11 Tower kernel: br0: port 2(vnet0) entered blocking state Oct 31 19:47:11 Tower kernel: br0: port 2(vnet0) entered disabled state Oct 31 19:47:11 Tower kernel: device vnet0 entered promiscuous mode Oct 31 19:47:11 Tower kernel: br0: port 2(vnet0) entered blocking state Oct 31 19:47:11 Tower kernel: br0: port 2(vnet0) entered forwarding state Oct 31 19:47:11 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth78a57fc: link becomes ready Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 6(veth78a57fc) entered blocking state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 6(veth78a57fc) entered forwarding state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 2(veth586c350) entered disabled state Oct 31 19:47:11 Tower kernel: veth11ca83e: renamed from eth0 Oct 31 19:47:11 Tower kernel: process '438eae849b24d6412344b81aa2b49509cdc8bec7dc8c49b2d1afc70a7781c84d/usr/bin/runsvdir' started with executable stack Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 7(veth52918f8) entered blocking state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 7(veth52918f8) entered disabled state Oct 31 19:47:11 Tower kernel: device veth52918f8 entered promiscuous mode Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 7(veth52918f8) entered blocking state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 7(veth52918f8) entered forwarding state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 2(veth586c350) entered disabled state Oct 31 19:47:11 Tower kernel: device veth586c350 left promiscuous mode Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 2(veth586c350) entered disabled state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 7(veth52918f8) entered disabled state Oct 31 19:47:11 Tower kernel: veth98df2d0: renamed from eth0 Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 6(veth78a57fc) entered disabled state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 6(veth78a57fc) entered disabled state Oct 31 19:47:11 Tower kernel: device veth78a57fc left promiscuous mode Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 6(veth78a57fc) entered disabled state Oct 31 19:47:11 Tower kernel: br0: port 3(vnet1) entered blocking state Oct 31 19:47:11 Tower kernel: br0: port 3(vnet1) entered disabled state Oct 31 19:47:11 Tower kernel: device vnet1 entered promiscuous mode Oct 31 19:47:11 Tower kernel: br0: port 3(vnet1) entered blocking state Oct 31 19:47:11 Tower kernel: br0: port 3(vnet1) entered forwarding state Oct 31 19:47:11 Tower kernel: eth0: renamed from vethad42d3d Oct 31 19:47:11 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth52918f8: link becomes ready Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 7(veth52918f8) entered blocking state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 7(veth52918f8) entered forwarding state Oct 31 19:47:11 Tower rc.docker: ApacheGuacamole: started succesfully! Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 2(veth4f468cb) entered blocking state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 2(veth4f468cb) entered disabled state Oct 31 19:47:11 Tower kernel: device veth4f468cb entered promiscuous mode Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 2(veth4f468cb) entered blocking state Oct 31 19:47:11 Tower kernel: br-9eca54687cab: port 2(veth4f468cb) entered forwarding state Oct 31 19:47:12 Tower kernel: eth0: renamed from vethc0ed865 Oct 31 19:47:12 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth4f468cb: link becomes ready Oct 31 19:47:12 Tower rc.docker: audiobookshelf: started succesfully! Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 6(vetha5c594e) entered blocking state Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 6(vetha5c594e) entered disabled state Oct 31 19:47:12 Tower kernel: device vetha5c594e entered promiscuous mode Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 6(vetha5c594e) entered blocking state Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 6(vetha5c594e) entered forwarding state Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 8(veth47b4537) entered blocking state Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 8(veth47b4537) entered disabled state Oct 31 19:47:12 Tower kernel: device veth47b4537 entered promiscuous mode Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 8(veth47b4537) entered blocking state Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 8(veth47b4537) entered forwarding state Oct 31 19:47:12 Tower kernel: eth0: renamed from veth9ab18f0 Oct 31 19:47:12 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vetha5c594e: link becomes ready Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 8(veth47b4537) entered disabled state Oct 31 19:47:12 Tower kernel: eth0: renamed from vetha86dc53 Oct 31 19:47:12 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth47b4537: link becomes ready Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 8(veth47b4537) entered blocking state Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 8(veth47b4537) entered forwarding state Oct 31 19:47:12 Tower rc.docker: authentik-worker: started succesfully! Oct 31 19:47:12 Tower kernel: docker0: port 4(vethbf847c0) entered blocking state Oct 31 19:47:12 Tower kernel: docker0: port 4(vethbf847c0) entered disabled state Oct 31 19:47:12 Tower kernel: device vethbf847c0 entered promiscuous mode Oct 31 19:47:12 Tower kernel: eth0: renamed from veth6eaba06 Oct 31 19:47:12 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethbf847c0: link becomes ready Oct 31 19:47:12 Tower kernel: docker0: port 4(vethbf847c0) entered blocking state Oct 31 19:47:12 Tower kernel: docker0: port 4(vethbf847c0) entered forwarding state Oct 31 19:47:12 Tower rc.docker: autobrr: started succesfully! Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 6(vetha5c594e) entered disabled state Oct 31 19:47:12 Tower kernel: veth9ab18f0: renamed from eth0 Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 6(vetha5c594e) entered disabled state Oct 31 19:47:12 Tower kernel: device vetha5c594e left promiscuous mode Oct 31 19:47:12 Tower kernel: br-9eca54687cab: port 6(vetha5c594e) entered disabled state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 6(veth2311415) entered blocking state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 6(veth2311415) entered disabled state Oct 31 19:47:13 Tower kernel: device veth2311415 entered promiscuous mode Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 6(veth2311415) entered blocking state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 6(veth2311415) entered forwarding state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(veth8573f30) entered blocking state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(veth8573f30) entered disabled state Oct 31 19:47:13 Tower kernel: device veth8573f30 entered promiscuous mode Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(veth8573f30) entered blocking state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(veth8573f30) entered forwarding state Oct 31 19:47:13 Tower kernel: eth0: renamed from veth4f3c387 Oct 31 19:47:13 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth2311415: link becomes ready Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(veth8573f30) entered disabled state Oct 31 19:47:13 Tower rc.docker: binhex-readarr: started succesfully! Oct 31 19:47:13 Tower kernel: eth0: renamed from veth218cc79 Oct 31 19:47:13 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth8573f30: link becomes ready Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(veth8573f30) entered blocking state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(veth8573f30) entered forwarding state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 10(vethbb02712) entered blocking state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 10(vethbb02712) entered disabled state Oct 31 19:47:13 Tower kernel: device vethbb02712 entered promiscuous mode Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 10(vethbb02712) entered blocking state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 10(vethbb02712) entered forwarding state Oct 31 19:47:13 Tower kernel: veth218cc79: renamed from eth0 Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 10(vethbb02712) entered disabled state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(veth8573f30) entered disabled state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(veth8573f30) entered disabled state Oct 31 19:47:13 Tower kernel: device veth8573f30 left promiscuous mode Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(veth8573f30) entered disabled state Oct 31 19:47:13 Tower kernel: eth0: renamed from vethf148afd Oct 31 19:47:13 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethbb02712: link becomes ready Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 10(vethbb02712) entered blocking state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 10(vethbb02712) entered forwarding state Oct 31 19:47:13 Tower rc.docker: Cloudflare-DDNS: started succesfully! Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(vethc40f401) entered blocking state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(vethc40f401) entered disabled state Oct 31 19:47:13 Tower kernel: device vethc40f401 entered promiscuous mode Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(vethc40f401) entered blocking state Oct 31 19:47:13 Tower kernel: br-9eca54687cab: port 9(vethc40f401) entered forwarding state Oct 31 19:47:14 Tower kernel: eth0: renamed from veth36fb9fc Oct 31 19:47:14 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethc40f401: link becomes ready Oct 31 19:47:14 Tower rc.docker: code-server: started succesfully! Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 11(veth1cdc640) entered blocking state Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 11(veth1cdc640) entered disabled state Oct 31 19:47:14 Tower kernel: device veth1cdc640 entered promiscuous mode Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 11(veth1cdc640) entered blocking state Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 11(veth1cdc640) entered forwarding state Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 12(vethf5b42da) entered blocking state Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 12(vethf5b42da) entered disabled state Oct 31 19:47:14 Tower kernel: device vethf5b42da entered promiscuous mode Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 12(vethf5b42da) entered blocking state Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 12(vethf5b42da) entered forwarding state Oct 31 19:47:14 Tower kernel: eth0: renamed from veth74b1daf Oct 31 19:47:14 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth1cdc640: link becomes ready Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 12(vethf5b42da) entered disabled state Oct 31 19:47:14 Tower rc.docker: cross-seed: started succesfully! Oct 31 19:47:14 Tower kernel: eth0: renamed from vethae8c5fe Oct 31 19:47:14 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethf5b42da: link becomes ready Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 12(vethf5b42da) entered blocking state Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 12(vethf5b42da) entered forwarding state Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 13(veth07df4c7) entered blocking state Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 13(veth07df4c7) entered disabled state Oct 31 19:47:14 Tower kernel: device veth07df4c7 entered promiscuous mode Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 13(veth07df4c7) entered blocking state Oct 31 19:47:14 Tower kernel: br-9eca54687cab: port 13(veth07df4c7) entered forwarding state Oct 31 19:47:15 Tower kernel: eth0: renamed from vethcf85505 Oct 31 19:47:15 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth07df4c7: link becomes ready Oct 31 19:47:15 Tower rc.docker: flaresolverr: started succesfully! Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 14(vetha1df482) entered blocking state Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 14(vetha1df482) entered disabled state Oct 31 19:47:15 Tower kernel: device vetha1df482 entered promiscuous mode Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 14(vetha1df482) entered blocking state Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 14(vetha1df482) entered forwarding state Oct 31 19:47:15 Tower kernel: vethae8c5fe: renamed from eth0 Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 14(vetha1df482) entered disabled state Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 12(vethf5b42da) entered disabled state Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 12(vethf5b42da) entered disabled state Oct 31 19:47:15 Tower kernel: device vethf5b42da left promiscuous mode Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 12(vethf5b42da) entered disabled state Oct 31 19:47:15 Tower kernel: eth0: renamed from vethbff833b Oct 31 19:47:15 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vetha1df482: link becomes ready Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 14(vetha1df482) entered blocking state Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 14(vetha1df482) entered forwarding state Oct 31 19:47:15 Tower rc.docker: freshrss: started succesfully! Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 12(vethb0051d2) entered blocking state Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 12(vethb0051d2) entered disabled state Oct 31 19:47:15 Tower kernel: device vethb0051d2 entered promiscuous mode Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 12(vethb0051d2) entered blocking state Oct 31 19:47:15 Tower kernel: br-9eca54687cab: port 12(vethb0051d2) entered forwarding state Oct 31 19:47:16 Tower kernel: veth74b1daf: renamed from eth0 Oct 31 19:47:16 Tower kernel: br-9eca54687cab: port 12(vethb0051d2) entered disabled state Oct 31 19:47:16 Tower kernel: br-9eca54687cab: port 11(veth1cdc640) entered disabled state Oct 31 19:47:16 Tower kernel: br-9eca54687cab: port 11(veth1cdc640) entered disabled state Oct 31 19:47:16 Tower kernel: device veth1cdc640 left promiscuous mode Oct 31 19:47:16 Tower kernel: br-9eca54687cab: port 11(veth1cdc640) entered disabled state Oct 31 19:47:16 Tower kernel: eth0: renamed from veth1bbdd25 Oct 31 19:47:16 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethb0051d2: link becomes ready Oct 31 19:47:16 Tower kernel: br-9eca54687cab: port 12(vethb0051d2) entered blocking state Oct 31 19:47:16 Tower kernel: br-9eca54687cab: port 12(vethb0051d2) entered forwarding state Oct 31 19:47:16 Tower rc.docker: gravkim: started succesfully! Oct 31 19:47:16 Tower kernel: docker0: port 5(veth612c094) entered blocking state Oct 31 19:47:16 Tower kernel: docker0: port 5(veth612c094) entered disabled state Oct 31 19:47:16 Tower kernel: device veth612c094 entered promiscuous mode Oct 31 19:47:16 Tower kernel: docker0: port 5(veth612c094) entered blocking state Oct 31 19:47:16 Tower kernel: docker0: port 5(veth612c094) entered forwarding state Oct 31 19:47:16 Tower kernel: eth0: renamed from veth00aef49 Oct 31 19:47:16 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth612c094: link becomes ready Oct 31 19:47:16 Tower rc.docker: heimdall: started succesfully! Oct 31 19:47:16 Tower kernel: br-9eca54687cab: port 11(vethe8f2862) entered blocking state Oct 31 19:47:16 Tower kernel: br-9eca54687cab: port 11(vethe8f2862) entered disabled state Oct 31 19:47:16 Tower kernel: device vethe8f2862 entered promiscuous mode

I am helping my father who does not live with me with some remote tech support. I need him to be able to access a SMB share on my UNRAID server. Our subnets are the same, so I need to connect via the server's wireguard network IP instead of its local IP. I connected his (Mac) laptop via Wireguard. I can access the UNRAID admin page, but when I try and connect via SMB it says there was an error connecting to the server. I think this may have to do with the fact that SMB is not listening on the wireguard network. As discussed, I cannot use the local IP even though remote access to LAN is setup because of the fact that both my and my parents subnets are the same (192.168.1.0/24). Is there a way to listen for SMB connections over the wireguard interface?

Right - I think one solution would be to change my networks subnet (or my fathers). But trying to avoid doing that because my reverse proxy often hard links to IPs.

I am helping my father who does not live with me with some remote tech support. I need him to be able to access a SMB share on my UNRAID server. Our subnets are the same, so I need to connect via the server's wireguard network IP instead of its local IP. I connected his (Mac) laptop via Wireguard. I can access the UNRAID admin page, but when I try and connect via SMB it says there was an error connecting to the server. I think this may have to do with the fact that SMB is not listening on the wireguard network. As discussed, I cannot use the local IP even though remote access to LAN is setup because of the fact that both my and my parents subnets are the same (192.168.1.0/24). Is there a way to listen for SMB connections over the wireguard interface>

It was the myservers plug-in and it’s a problem that’s been fixed. What wound up helping me was I uninstalled all plugins and slowly added them back in. Same could be said for docker but that wasn’t causing the issue.

I tried to set this up after reading that it works (and 6.10 does not). I get the following errors: Failed to fetch record! error in mds_init_ctx for: /opt/timemachine _mdssvc_open: Couldn't create policy handle for TimeMachine error in mds_init_ctx for: /opt/timemachine _mdssvc_open: Couldn't create policy handle for TimeMachine talloc: access after free error - first free may be at ../../tevent_req.c:291 Bad talloc magic value - access after free =============================================================== INTERNAL ERROR: Bad talloc magic value - access after free in pid 48 (4.15.7) If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting =============================================================== PANIC (pid 48): Bad talloc magic value - access after free in 4.15.7 unable to produce a stack trace on this platform dumping core in /var/log/samba/cores/smbd Does anyone have any advise as to how to resolve?

I had my DNS set to my routers IP or the adguard container's IP (which had its own IP) in Unraid's network settings. Everything was working as intended. When I rebooted after the update, Unraid itself did not have DNS (for example I could not ping google.com) and neither did the containers. I had to set my DNS in network settings to 8.8.8.8 to resolve. The problem is now I cannot use my split DNS within my containers. Is there a reason why I cannot set my DNS to a container on Unraid? Or why this was working but stopped? The other day when I tried to unsuccessfully setup wireguard, all my containers went down on uptime kuma running on a pi. I don't know if that could be related. This was resolved after disabling the wireguard network. Edit: I think this has something to do with wireguard. After the reboot, the wireguard network was active. I could not ping my router. I got some error and reference to the wireguard network. I guess I have kind of solved my issue: just don't use wireguard. But I am curious what is actually happening here?

Deleting CA Backup/Restore Appdata, Docker Folder seems to have stopped the writes after rebooting in regular (not safe) mode. Next I plan to reinstall MyServers after a couple hours of stability. I suspect that CA Backup/Restore Appdata is my issue because that is the newest plugin. Maybe I will try and duplicate via rsync or something instead. Leaving this open until I can confirm over a longer time period, but we may have just solved this!

Alright - safe mode has stopped the writes! I suspect it might be the cache backup plugin only because that is new. My questions are: 1. Is the only difference in safe mode the fact that plugins don't run? 2. Assuming 1 is yes, knowing that it is probably plugins causing my problems, is there a better way to pinpoint or should I just disable all plugins and slowly re-enable?

I’m up to 9434 writes after removing the My Servers and preclear plugin/docker. So still writing about 200 an hour.

Thanks for the response. I uninstalled MyServers and the Unassigned Drives plugin (no longer need so might as well rule one more thing out). It doesn't look like I have preclear installed as a plugin, I think I used a docker instead. Because docker is not currently enabled I have not uninstalled that but I do not think that should matter. I will uninstall once I restart docker just in case. I am at 8759 writes. I keep listing them here for my own record.

I am at 8194 writes after disabling the docker service. So about 400 in 1 hour. I don't think that fixed the USB writes. Thus I do not think it is the VM or Docker services causing the massive amount of writes.

I disabled the VM service. I left docker service on but stopped all containers. In 1 hour 45 min I went from 6938 to 7500 writes. I’m now disabling the docker service to see if that makes a difference. One other recent change (maybe this matters maybe it doesn’t), other than my rebuild was that I implemented a cache array. Right now it is just system, appdata, and domains on there. i will update in an hour or two now that I have disabled docker service to see what the write situation is. edit: 7777 writes.

Nothing displayed so I am assuming the answer is no. I am up to 5629 writes now. so in the 19 hours I posted, an additional 4000+ writes. Actually 5634, it just keeps creeping up and up. I just looked at the output of the ls -ltR /boot command again and there was nothing in the last couple minutes. Is there some other folder I can look at or is the USB limited to the /boot folder? edit: could this be a bug? I am very sensitive to this because I lost a USB drive this month and don't want to lose a second drive within 30 days.

Does it make sense that the most recent write was 2 hours ago, but there are about 500 more writes since then? Thanks for the suggestion.