snz

Hi everyone, I’ve been running into a recurring issue over the past month where all my SMB shares suddenly become inaccessible, and the syslog fills with messages like this: smbd[363134]: chdir_current_service: vfs_ChDir(/mnt/user/3D-ZFS) failed: Transport endpoint is not connected When this happens: All /mnt/user/* shares break — ls /mnt/user gives: ls: cannot access '/mnt/user': Transport endpoint is not connected Docker containers and VMs that use user shares also fail. SMB shares disappear from the network. This has now happened 3 times in the past month. Here’s a snippet of the log during the event: chdir_current_service: vfs_ChDir(/mnt/user/3D-ZFS) failed: Transport endpoint is not connected. make_connection_snum: canonicalize_connect_path failed for service 3D-ZFS, path /mnt/user/3D-ZFS Restart seems to solve the issue but understandably this isn't going to work for me long term. tower-diagnostics-20251021-1003.zip

It was the psu. replaced it. has been up for 24 with no drops. thanks for your support once again.

Have sent the output of previous syslog file after enabling it to write to flash. running memtest currently I'm wondering if its its the XMP profile being enabled?

What I’ve found is the machine reboots. That’s why there is a network connectivity drop. i will send you some syslog files if that helps? these are the ones written to the usb flash drive

So it just crashed again. And this is all the syslog shows right before the crash.. @JorgeB - Are you able to assist? Apr 1 17:08:11 Tower kernel: eth0: renamed from veth77bbdde Apr 1 17:08:11 Tower kernel: docker0: port 21(vethac00eb9) entered blocking state Apr 1 17:08:11 Tower kernel: docker0: port 21(vethac00eb9) entered forwarding state Apr 1 17:08:13 Tower kernel: docker0: port 21(vethac00eb9) entered disabled state Apr 1 17:08:13 Tower kernel: veth77bbdde: renamed from eth0 Apr 1 17:08:13 Tower kernel: docker0: port 21(vethac00eb9) entered disabled state Apr 1 17:08:13 Tower kernel: vethac00eb9 (unregistering): left allmulticast mode Apr 1 17:08:13 Tower kernel: vethac00eb9 (unregistering): left promiscuous mode Apr 1 17:08:13 Tower kernel: docker0: port 21(vethac00eb9) entered disabled state Apr 1 17:09:13 Tower kernel: docker0: port 21(veth53a2953) entered blocking state Apr 1 17:09:13 Tower kernel: docker0: port 21(veth53a2953) entered disabled state Apr 1 17:09:13 Tower kernel: veth53a2953: entered allmulticast mode Apr 1 17:09:13 Tower kernel: veth53a2953: entered promiscuous mode Apr 1 17:09:14 Tower kernel: eth0: renamed from vethafb4327 Apr 1 17:09:14 Tower kernel: docker0: port 21(veth53a2953) entered blocking state Apr 1 17:09:14 Tower kernel: docker0: port 21(veth53a2953) entered forwarding state Apr 1 17:09:16 Tower kernel: docker0: port 21(veth53a2953) entered disabled state Apr 1 17:09:16 Tower kernel: vethafb4327: renamed from eth0 Apr 1 17:09:16 Tower kernel: docker0: port 21(veth53a2953) entered disabled state Apr 1 17:09:16 Tower kernel: veth53a2953 (unregistering): left allmulticast mode Apr 1 17:09:16 Tower kernel: veth53a2953 (unregistering): left promiscuous mode Apr 1 17:09:16 Tower kernel: docker0: port 21(veth53a2953) entered disabled state

Appears that the logs only go back to the time the server came back online. I assume I now need to enable syslog to USB Flash so that I can capture the logs for when it happens next in a place that is persistent.

Here you go. It went down just now at 9.48AM 1/4/2024 (First of April 2025) The parity check that was going on got cancelled too.tower-diagnostics-20250401-0951.zip I couldn't access the server via network but console with keyboard and mouse I could.

Yes can access it using keyboard and mouse. It appears to sort of restart its array (VM/Docker servers also) but itself and comes back up. I also uninstalled the SR-IOV plugin for more testing

Apologies and thank you for moving it. - removed powertop - removed second NIC from config file. will restart and continue to monitor.

Hi everyone, I’m experiencing an issue where my Unraid server’s network keeps going down and back up intermittently. It happened just now around 8:50 PM on 29/03/2025. This has been occurring randomly, and I’m trying to figure out what’s causing it. Some details about my setup: • Unraid version: 7.0.1 • Network setup: using unifi flex 2.5gb switch but all other clients remain online when this happens. • Any recent changes: i did change the ram models but is this something that could cause this? I would have thought bad ram would cause it to crash completely.tower-diagnostics-20250329-2055.zip I’ve attached diagnostics from the time of the issue. If anyone can help analyze the logs or point me in the right direction, I’d really appreciate it! Thanks in advance.

I've runt Powertop --autoconfig (or the equiv. command) but am not seeing any reduction in power using C States. Is this likely due to me having 2 VM's running? Have enabled the CStates settings in Bios to L0 and L1s as well. Taken them off auto. PRO B660M-A WIFI DDR4 (MS-7D43) with a Intel i3 13100 CPU.

Thank you so much for posting this!!! You helped solve the issue of the Error 43 I was having above!

Update: I shut down the VM Uninstalled the plugin rebooted the server reinstalled the plug in set the virtual card number to one. restarted the server.. reassigned the virtual GPU and still no success. any help would be appreciated. attaching screenshot of the error I am facing. as well as a screenshot of how it looked before I assume the vdisk got corrupted not allowing me to boot from it.

Very wierd behaviour. My VM running Blue Iris hosted on Unraid with the plugin installed was working perfectly. CPU: 13100 i3. UHD 730 was showing up in Task Manager perfectly. Then the VM stopped booting so I created a new one. However, the new one is showing Error 43 in the Device manager. I have a screenshot of the old config and the new one. Could someone please help me troubleshoot? Old Config: New config: