dlandon

That's a normal message that doesn't mean anything: Jun 20 16:24:30 BackupServer rpc.statd[6882]: Failed to read /var/lib/nfs/state: Success That's from my system and NFS is working. That's not the problem. That's why the full diagnostics are necessary. Nothing with NFS has changed. If you're doing a custom exports file, remove your custom settings and see if NFS will start.

Post diagnostics.

Is your time, date, and timre zone set correctly?

I just found this message in your log: Jun 10 16:17:53 Raster unassigned.devices: Remote server 'NASCEB6D5' cannot be found on the LAN. That means that UD can't fnd that server. Check the IP address of the QNAP server. Go to a terminal on Unraid and try to ping the QNAP server. I have just found some issues with the way UD is getting IP addresses of remote servers. It may be part of the issue you are seeing.

There have been networking changes that may have affected UDs ability to find other servers. UD uses arp to get the IP addewss of the server and then pings that server to confirm it is online. I'm not sure how Docker can affect it. The ping is tickling something. UD has no visibility into a ping on another server if it has not done the ping. UD depends on its own arp command to get the IP address of the server. I have found an issue with specifying the FQDN that might be related to what you are seeing. I need to do some more testing before it is released, but it may solve your issue.

Here is the way UD works: Use 'arp -a DISKSTATION' to get the IP address. If the IP address is returned, it is used. If the IP address is not returned UD uses 'arp -an DISKSTATION.MYDOMAIN.LOCAL' to get the IP address. I think the issue is that your pihole is supplying the IP address when it is running. I assume it is a Docker Container. And it is the wrong IP address? EDIT: I may have found something.

Post diagnostics when the mount fails so I can see the log entries and see why UD is having trouble.

Is 10.0.0.252 correct for your DNS server? Do the devices become mountable after some time? You have a 20 second delay before UD auto mounts the devices. Is that maybe not long enough now? Try the following if the devices are not mountable after some time: Remove one of your shares and use the IP address, not the server name and see if it will show the remote share as mountable.

Post diagnostics.

There have been networking changes made in the latest release that probably affects this. Is the Synology NAS on the same LAN as the Unraid server, or remote through Wireguard?

It looks like there is a fix in the next release of 6.12. Seems that the Samba configuration is reloaded at times and the 'interface' parameter is not applied correctly. It takes a Samba restart as you found out when you did a Samba restart. What's strange is that it looks correct in testparm.

Provide diagnostics then. The original poster is still on 6.11.0.

Start by updating to a later stable version like 6.11.5 or preferrably 6.12.

Not necessarily, the mover is very chatty and makes the log hard to read though. That is not helping your log filling issue. That being said, the stale file handle messages seem to appear when the mover is running. Once you get your networking sorted out, post the diagnostics when the stale file handle messages appear again. I would also try running your system without any Docker Containers running to see if that's contributing to the stale file handle messages. I saw some log messages about the minecraft Docker Container that didn't look right.

Use UD (Unassigned Devices Plugin) to mount remote NFS shares. UD handles the remote shares properly. It's hard for us to support fstab mounts because of all the specific settings and user misconfiguration.

You have multiple things going on: Jun 16 19:45:29 Tower rc.docker: pihole: Error response from daemon: network br0 not found Jun 16 19:45:29 Tower rc.docker: Error: failed to start containers: pihole Jun 16 19:46:15 Tower root: Minecraft-polytech-direwolf20-1.19: Could not download icon https://vignette.wikia.nocookie.net/minecraft/images/7/7b/Grass_block.png Jun 16 19:46:15 Tower root: urBackup-Server: Could not download icon http://192.168.1.90:55414/images/urbackup.png Jun 16 19:46:24 Tower smbd[17971]: [2023/06/16 19:46:24.485175, 0] ../../source3/smbd/close.c:1397(close_directory) Jun 16 19:46:24 Tower smbd[17971]: close_directory: Could not get share mode lock for polytech-direwolf20-1.19 Jun 16 19:46:24 Tower smbd[17971]: [2023/06/16 19:46:24.485224, 0] ../../source3/smbd/fd_handle.c:39(fd_handle_destructor) Jun 16 19:51:00 Tower root: Fix Common Problems Version 2023.04.26 Jun 16 19:51:00 Tower root: Fix Common Problems: Error: eth0 does not have a valid IP address You have networking issues you need to straighten out. I'd also get all your Docker Containers updated and turn off mover logging.

Do this command in a terminal: chown -R nobody:users /mnt/disks/One_Touch/

I suspected that. I'm out of ideas for the moment.

I've seen this before. Power off the server and re-seat the nvme disk. Then reformat.

It all looks right. See if you have this setting in Wireguard:

On the system that works, I am amazed it works at all. You have a lot of network down messages in the log: Jun 16 18:49:40 Lucy unassigned.devices: Successfully mounted '//NASCEB6D5/Backup-Unraid' on '/mnt/remotes/NASCEB6D5_Backup-Unraid'. Jun 16 18:49:40 Lucy unassigned.devices: Device '//NASCEB6D5/Backup-Unraid' is not set to be shared. Jun 16 18:50:01 Lucy kernel: igb 0000:04:00.0 eth0: igb: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX Jun 16 18:50:01 Lucy kernel: igb 0000:04:00.0 eth0: Link Speed was downgraded by SmartSpeed Jun 16 18:50:01 Lucy kernel: bond0: (slave eth0): link status definitely up, 100 Mbps full duplex Jun 16 18:50:02 Lucy kernel: igb 0000:04:00.0 eth0: igb: eth0 NIC Link is Down Jun 16 18:50:02 Lucy kernel: bond0: (slave eth0): link status definitely down, disabling slave Your network appears to be dropping on 'raster': Jun 14 18:59:55 Raster kernel: igb 0000:04:00.0 eth0: igb: eth0 NIC Link is Down Jun 14 18:59:55 Raster kernel: bond0: (slave eth0): link status definitely down, disabling slave Jun 14 18:59:55 Raster kernel: device eth0 left promiscuous mode Jun 14 18:59:55 Raster kernel: bond0: now running without any active interface! Jun 14 18:59:55 Raster kernel: br0: port 1(bond0) entered disabled state Jun 14 18:59:56 Raster dhcpcd[1542]: br0: carrier lost Jun 14 19:00:01 Raster kernel: igb 0000:04:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Jun 14 19:00:01 Raster kernel: bond0: (slave eth0): link status definitely up, 1000 Mbps full duplex Jun 14 19:00:01 Raster kernel: bond0: (slave eth0): making interface the new active one I don't think you've done any network configurayion on 'raster'. You should, and I would recommend you assign a static IP address. Do this: Confirm your network settings on both servers. Work on getting rid of the network errors on both servers. Check the rest of your network setup (cables, switch, router, etc). I think the network errors are causing your issues.

So it shows 192.168.50.200/24 in the network setup? Do this command when SMB is working and see if the 'interfaces' command has the /24 added to 192.168.50.200: testparm -s it will be near the top.

I wish you'd have told me that sooner. What are the differences between the servers? Are both on the same local network with the QNAP? Any access through Wirequard?

That's good information, thanks. I tried to reproduce your issue and I couldn't. Unraid 6.12 sets up some networking for Samba to be sure it is only listening on the appropriate interfaces - the 'interfaces' command. I don't know how you have your networking setup, but those 'interfaces' are the IP addresses that Samba is listening on. What are you doing with the Wireguard interface? The 127.0.0.1 is the localhost or 'lo'. What I don't understand is why you had to restart Samba to get SMB shares to be visible. I see one thing I'd like you to check. Take a look at your networking setup and confirm this setting: I'm suspicious because the 'interfaces' in my test system shows: interfaces = 192.168.1.4/24 127.0.0.1 notice the /24? You're missing the mask. This really shouldn't have anything to do with needing to restart Samba, but I'm a little suspicious the 'interfaces' is not getting set properly in a certain case keeping SMB shares from being visible, and a Samba restart fixes it.

Sequence of events to start services after setting up network? Samba is restarted on array start and stop.