rjdipcord

Adding to the NO list are these three: The Kingston MobileLite Plus USB 3.2 SDHC/SDXC UHS-II Card Reader (MLP) And the acer SD Card Reader USB C, Dual Slots USB 3.0 Type C to Micro SD Card Adapter, Memory Card Reader for MicroSD, SDHC, SDXC, Compatible with Laptop, PC, iPhone16/15, MacBook Pro/Air, iPad Pro, Android And the Insignia™ - USB 3.0 SD and microSD Memory Card Reader - Black All of which had a non-unique GUID. Not usable for UNRAID activation.

Done! LilNAS-X-tailscale-diag-20240930-214327.zip

All of the settings I detailed are things I added in attempt to get SMB working. So no, it did not work out of the box. Without "tailscale1" listed in my interface extra area, GUI access, and any other bridged services is lost. Using this intuition, I added tailscale1 to the SMB interfaces section in attempt to get SMB passing over TS. Obvioulsy. That didn't help.

Thanks for the reply. Yes. I am trying to access my shares over tailscale using Samba Protocol or "SMB", as you would through a windows-mapped network drive. SMB is accessible over my LAN network with zero problems. But I cannot get it to talk over TS.

Hello all, I am at my wits end. Cannot figure out why SMB does not work across tailscale. It works exactly as expected for GUI access and other services. I can access the interfaces of containers using the bridge interface just fine. SMB, however, refuses to establish connectivity across the tailscale1 interface. I am running Unraid 7.0.0-beta.2. With that said, I am using the tailscale plugin. Tailscale is configured to pass Unraid services. SMB is configured to use the tailscale1 interface. And interface extra has tailscale1 listed as included. Note this screenshot. It may be the source of my issue: isn't 'current listening interfaces' supposed to list off? Like this? If so, why isn't mine? Is there anything about my configuration that definitely shouldn't work? lilnas-x-diagnostics-20240928-2156(1).zip

Hello all, I am at my wits end. Cannot figure out why SMB does not work across tailscale. It works exactly as expected for GUI access and other services. I can access the interfaces of containers using the bridge interface just fine. SMB, however, refuses to establish connectivity across the tailscale1 interface. I am running Unraid 7.0.0-beta.2. With that said, I am using the tailscale plugin. Tailscale is configured to pass Unraid services. SMB is configured to use the tailscale1 interface. And interface extra has tailscale1 listed as included. Note this screenshot. It may be the source of my issue: isn't 'current listening interfaces' supposed to list off? Like this? If so, why isn't mine? Is there anything about my configuration that definitely shouldn't work? lilnas-x-diagnostics-20240928-2156.zip

This seems to have been related to the 'Community Apps' plugin (or perhaps other plugins) not being up to date. I updated all plugins and the Update and Downgrade OS screens came back to life.

Hi All. My Upgrade and Downgrade screens are blank with no options. Why is this? I restarted my machine. Stopped the array and checked. Restarted the array and checked. No idea what's going on. lilnas-x-diagnostics-20240627-1501.zip

Hi all. Really strange issue i'm having. My Unraid instance is frequently adding a bad route to my IP routing table. In the above pic, the 3rd rule down is incorrect. br1 is on the 10.0.0.0/24 subnet, and br0 is on the 10.0.5.0/28. When the 3rd rule is in place, it receives no metric, so I assume it is 0, and then all traffic begins moving through that route. Since this is the wrong subnet for that traffic, my firewall drops all packets and the server becomes unreachable. I am only able to access it by changing my firewall rules to temporarily allow traffic across my VLAN, or by changing the IP tables on the command line. I feel like I should mention, it's actually impossible to resolve this issue via the GUI. It does not permit you to delete the bad route. I can delete all other rules, but that doesn't help me so I try to avoid that. In the syslog, I notice a service called "avahi-daemon" registering address records for IPs in the 10.0.0.0/24 subnet on the wrong interface, br0. I feel this may be the service that's causing my grief, but I do not know what it is or how to observe it. Any ideas?? lilnas-x-diagnostics-20240621-0025.zip

The community plugin User Scripts should allow you to achieve this.

Yes that makes sense. When traffic passes through the WAN port, it is also passing through a firewall. That firewall is designed to protect the devices behind it and allow only minimal traffic through. It has no way of knowing the traffic you're trying to pass is actually allowed, and will perform the default action - drop the packets. You should evaluate your network topology and make sure there are no unnecessary routing paths that could be redundant and causing issues.

Your logs are stating the mover hasn't moved anything for 18 hours. It was running at 03:00 but that was the last time it published any log entries. Something might be hung up. Check your cache drive for any leftover files and I would suggest rebooting after that.

I figured out my issue. My network routing table was causing my problems. ( I don't understand why it was a problem so suddenly, but that's a question to ask if it randomly happens again) I have br0 and br1 for docker stuff. Two incoming connections, eth0 and eth1. eth0 is on my DMZ subnet and attached to br0, eth1 is on my LAN at 10gbps and is attached to br1. The metric for br0 was 1, while br1 had no metric. I changed br0 to 3 and br1 to 1 just in case I want to add a second 10gbps connection later. Now, traffic to and from the LAN network works fine! The incorrect config caused issues because I have firewall rules to limit traffic to and from the DMZ. If traffic tries to escape the DMZ on any address besides the gateway, it is dropped. As such, pings to the 10.0.0.0/24 subnet would get dropped because unraid was routing outbound traffic through the DMZ due to that metric being too low on br0. Since it was DMZ traffic, it could not physically reach the LAN.

As a suggestion, take a look into inter-container networks within docker. You can actually route traffic between containers using dedicated virtual networks within docker. If you do it this way, you completely mitigate Layer 2 and Layer 3 routing for your services, thus reducing bandwidth on your LAN.