dlandon

That's not a weird solution. What that means is that the name resolution is taking a while and using the IP address that doesn't rely on name resolution gets past that.

Your wait timer before mounting remote shares is 30 seconds. Make that several minutes and see if that's enough time for things to get settled and allow the mounts.

It looks to me like the remote shares are auto mounting because 30 seconds after UD says it's waiting 30 seconds, the remote shares start mounting. But two did not mount. Then I see where you loged in and mounted two manually: Yes. There may not be long enough time waiting for the remote server to be available. There is a UD setting that sets how long UD will wait to mount remote shares. Currently you have it set for 30 seconds: Mar 8 07:32:10 Monolith-6 unassigned.devices: Waiting 30 secs before mounting Remote Shares... The setting is 'Remote share mount wait time' in Settings->Unassigned Devices. UD will also attempt to update the online status before trying to mount remote shares, so it should automatically get the current status before mounting.

It looks to two shares from one remote server that won't mount: The server offline means the server port for NFS (port 2049) is not open on that server. UD does not ping anymore to check for a server being online.

Post diagnostics.

Based on all you've been through, I think it might be time to look at hardware issues: Do a memory test. As @JorgeB suggested boot Unraid on an old laptop or another computer and test the file transfer. Replace motherboard and processor?

No. The apfs driver used in UD is read only.

Set up cache_dirs to only include the folders you really need to be scanned. Don't use the default settings. It will end up scanning everything causing the issue you see.

Post your diagnostics so I can see how your system is set up.

The method for determining if a remote server share is available has changed from a ping to checking if the port is open for SMB on the remote server. Check that SMB is enabled on your remote server. Also, be sure port 445 is open on the remote server and it is not being blocked by tail scale or a firewall.

Do the following: Post diagnostics. Click on the double arrows icon in the upper right of the UD page.

If it were me, I'd boot in safe mode and verify SMB was working, then add back plugins and dockers until it stops.

Yes. That won't change the configuration, but will update the system and might be worth a try. I would do this of the two choices.

That looks like it might be a port issue. SMB uses porrt 445. Is there a chance it's being blocked somewhere or in use by a docker or VM somehow? It's very close to port 443 used by https://.

I'm actually in Texas, US of A. I really don't see anything in the diagnostics that necessarily indicates an SMB issue. I'm leaning towards a network/routing issue. I see a few things that should be checked/confirmed: Gateway is 192.168.50.1 but DNS server is 192.168.50.5. Is this correct? It appears the router is supplying the Unraid IP because Unraid is setup to use DHCP? You have said you can ping and log into Unraid so I'm confused why SMB wouldn't work, especially when using the IP address. There is a domain defined - 'loesle'. I suspect this may have been from using AD at some point and is left over. You might try re-configuring SMB Settings. Change a setting and the apply it to regenerate the config file. Do the same for your network settings. As a side note, your access to Unraid is limited to http://. Redo the 'Management Access" settings and enable https://.

Allowing all of the timeouts in UD to be programmable would not be practical. There is no way short of testing this timeout on every possible remote server there is to know the right timeout. The latest version of UD increases the time out to 15 seconds.

There are several things that can affect SMB performance. Some of these things are: Network issues. SMB configuration. Unraid array configuration. I've seen a lot of mis-configured and poor network configurations. This can have an impact on what appears to be SMB issues. The biggest issue with networking I see is users trying to set up Jumbo frames and don't get it right. The way you have your shares set up can affect performance. The "Allocation Method" for distributing files in the array can have an impact. I believe the "High-water" method tends to be faster. As for SMB configuration, Unraid configures SMB to be most compatible. Making the SMB Extras adjustments suggested above can help in a particular situation, but would not be the "most compatible". The "store dos attributes = no" setting turns off the following settings if they are on: map archive = Yes map hidden = No map readonly = no map system = No These are the default Unraid settings, so the only one that is changed is the "map archive". This is the DOS file system archive bit. As for the "ea support = no", this disables extended file attributes. Extended file attributes are used on xfs and btrfs file systems in Linux and turning this off may impact their operation in Unraid depending on what applications are using the Unraid files and if they need extended attributes. So while I appreciate that maximum SMB speed is desireable, applying these "tweaks" to Unraid is not in the best in the interest of compatibility. You are free to do these tweaks in SMB Extras for your particular needs with the understanding of the potential downside. The calls for action "why don't the Unraid devs fix this", is a tough one for Limetech: Samba is open source software that Limetech has no control over. The Samba team has to pretty much reverse engineer SMB because Microsoft is not that forthcomming about SMB functionaliy. Limetech configures SMB the best it can based on keeping the most compatibility. If we can come up with SMB configurations that can help with responsiveness and maintain compatibility, we can definitely implement that. There is one SMB setting I've implemented in UD that might help. If someone can spin up a UD disk and share it with SMB and let me konw if the browsing is improved I can work on implementing that in core Unraid. The setting is: vfs objects = dirsort An SATA disk would be best because USB disks tend to be slower. Be sure to have MacOS compatibility turned off because it blocks this setting. You can't set this manually in SMB Extras because it overwrites other "vfs objects" settings in SMB since SMB Extras are global settings. The downside to the setting is that there is more processing time to sort the directories. I suspect this is similar to the Windows indexing. EDIT: Another setting to try is "Case-sensitive Names" in Share Settings. Read the setting Help by clicking on the setting description and see if a different setting will help.

Format the disk as an encrypted disk.

Neither and it's not a bug. Unraid assigns unassigned disks the 'devX' designation. UD changes the 'devX' to 'Dev X' to make it a little clearer. Given a little time and UD should update the 'dev1' on the GUI.

I'm not seeing how this is a UD problem. Enlighten me.

That's what FIle Activity does.

Special characters can cause issues with php. Try to avoid using a '+' in your passwords.

That timer is the time to wait before starting to mount the remote shares. This insures the network is ready, it has nothing to do with the time to mount shares. No, it's hard coded. Post your disgnostics so I can be sure to come up with the correct solution.

There is not enough performance on a flash drive to run a VM, and any USB connected device will suffer from performance and reliability issues.

Just did. It will be in the next reelease of UD.