Jump to content

54lzy

Members
 View Profile  See their activity

  • Posts

    27

  • Joined

  • Last visited

 Content Type 

Posts posted by 54lzy

    Issue connecting to internet (but not wireguard network)

    in General Support

    Posted

    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.

    Issue connecting to internet (but not wireguard network)

    in General Support

    Posted

    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:

    image.thumb.png.75345c14e56892034c7b876616328140.png

     

    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.

    VM window frozen, tried to restart, then server crashed

    in General Support

    Posted

    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.

    VM window frozen, tried to restart, then server crashed

    in General Support

    Posted

    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
     

    SMB share over wireguard using wireguard network interface

    in General Support

    Posted

    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?

    Cannot connect to smb share over Wireguard VPN

    in File Sharing Protocol Support

    Posted · Edited by 54lzy

    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>

    Timemachine Application Support Thread

    in Docker Containers

    Posted · Edited by 54lzy
    formatting

    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?

    After a reboot/update setting DNS to Adguard Container no longer works

    in General Support

    Posted · Edited by 54lzy

    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?

    What is writing to my Unraid USB drive [Solved]

    in General Support

    Posted

    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!

    What is writing to my Unraid USB drive [Solved]

    in General Support

    Posted

    11 hours ago, trurl said:

     

    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?

    What is writing to my Unraid USB drive [Solved]

    in General Support

    Posted

    3 hours ago, 54lzy said:

    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’m up to 9434 writes after removing the My Servers and preclear plugin/docker. So still writing about 200 an hour.

    What is writing to my Unraid USB drive [Solved]

    in General Support

    Posted

    9 minutes ago, Squid said:

    uninstall preclear plugin followed by myservers plugin.  They're you're most likely culprits

    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.

    What is writing to my Unraid USB drive [Solved]

    in General Support

    Posted · Edited by 54lzy

    2 hours ago, remotevisitor said:

    I would try turning off the docker and VM service and see if it stops.    Then at least you know it is something to do with them.

     

    if it still continues, try booting in Safe mode from the Unraid boot menu, which will not load any plugins.   See if it now stops.

     

    if at any stage it stops it will then be a case of working through enabling your plugins/dockers/VMs to find which one is the cause.

     

    this number of writes to the flash drive is certainly not normal.

    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. 

    What is writing to my Unraid USB drive [Solved]

    in General Support

    Posted · Edited by 54lzy

    11 hours ago, remotevisitor said:

    Does seam a bit strange .

     

    how about trying ‘lsof +D /boot’ to see what has any open files on the flash.

    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.

    What is writing to my Unraid USB drive [Solved]

    in General Support

    Posted

    46 minutes ago, remotevisitor said:

    I would do an ‘ls -ltR /boot’ and look at the output to see what files have recently been changed to see if that gives any idea what might be writing to the flash drive

    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.

    What is writing to my Unraid USB drive [Solved]

    in General Support

    Posted · Edited by 54lzy

    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

    SMB Share with Export: Yes/Time Machine not showing in Mac Time Machine Settings

    in General Support

    Posted · Edited by 54lzy

    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!

    SMB Share with Export: Yes/Time Machine not showing in Mac Time Machine Settings

    in General Support

    Posted

    First let me say this previously worked. The only thing I can think of that has changed is I added the following line to my SMB settings: max protocol = SMB2_02.

     

    I have a new SMB share (and new Unraid install for that matter). I set export to Yes/Time Machine per the guides to set up Time Machine backup. All of a sudden my (incomplete) backup wasn't working. My Mac couldn't find the disk. I decided to delete the share and start from scratch. Now when I look for a drive to setup a time machine backup my share is not there. I have mounted the SMB share on my Mac so that is not the problem fix. Can someone advise how I can resolve this? Is it the line I added to my SMB settings? I would delete it but for some reason my parity check is running again.

×
×
  • Create New...