54lzy

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.

Adding "fruit:metadata = stream" to my SMB extras (as my only SMB extra) fixed my issue. Thank you for your help Oldbean56!

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.

It is not enabled and it is not set to mirror to the flash (it is set to Disabled, and mirror setting says No).

I recently had an "unclean shutdown." When I booted one disk was disabled so I removed and added to the array to fix. I am rebuilding my array. I noticed a lot of writes on my USB (6000 in 14 hours) so I rebooted my system. Bad move because now the rebuild has restarted. Now I am 2 hours into a boot with 1000 writes. I am wary because I had a USB drive fail me this month or last after tens of thousands or writes to it. Can anyone tell what is writing to my USB? I have uploaded my diagnostics. I am interested in knowing what to be looking at too (so I can solve this myself next time). tower-diagnostics-20210626-1402.zip

As an update, getting rid of the line I referenced in the custom SMB config did not fix the issue. The Time Machine share still does not show when trying to setup a new time machine backup. edit: after restarting the Mac and mounting the SMB drive I may have fixed this. I will post to be certain. I think it was from removing the SMB config language. I will update to be sure!

Is it safe to pause a parity check then stop the array? Last time I did that the parity check started from scratch. I can try after the parity check completes worst case. I'm running MacOS 11 with the latest patch.