Can never access SMB reliably- WHY?

[antigravity]

Loving unraid, but geez the SMB implementation is shocking. 

 

I can't for the life of me consistently access SMB shares on a basic local windows workgroup. WHY?

 

----SMB turned on

 

----Share turned on and access granted for user: media


----IP Address of server static


----RESULT

 

 

WHY?

Edited November 15, 2023 by antigravity

[MAM59]

normally it means that your windows pc is not using the credentials for "media" but uses the user that is logged on to windows.

You have to go to the (oops, no idea how it is called in english) "networkconnection management" setting and add an entry for 192.168... with the user name "media" and the proper password.

Afterwards you will need to reboot windows because there is already a (not working as you know) connection and it will not be dropped automatically.

 

After the reboot it should work.

 

[JonathanM]

credential manager

[antigravity]

Thanks - I checked and already have this here. I restarted both the Unraid server and the Windows PC and SMB access work. 

 

Fingers crossed it maintains over time- but it seems to continuously drop out/forget.

 

[MAM59]

From time to time windows renews the connection. And it MAY happen now and then, that it switches from IP Address to MDNS Name (Netbios Name) then.

So, it would be wise to create another credential entry with the same values for the name of the UNRAID box (default = TOWER, you have set it at the installation time of UNRAID).
This is because SAMBA works as the master Nameserver if there is nobody else in the windows network. And names are prefered.

Now and then the windows boxes find the SAMBA server and elect him as "workgroup master". From then on, names are used.

 

 

[Frank1940]

Windows SMB might consider the IP address of your Unraid server to be a different server then the same server with the 'Name' assigned to it.  (The Unraid default is TOWER)*

 

One good practice to leave your Unraid server on 24--7 so that it will be elected the 'Local Master'  (or 'workgroup master').  Long experience has shown that this results in a more stable SMB environment.  You can also insert the following code in your SMB Extras file to bias this election:

 

[global]
domain master = no
preferred master = yes
os level = 255

 

 

* This behavior was often used as a backdoor to allow a second user to log on a server from the same Client computer-- which Microsoft SMB will (attempt to) prevent from happening.  This may be plugged now as I haven't been able to get it to work for some time...

[Frank1940]

Let me ask one more question, do you access any shares on the server that are 'Public' or 'Secure'?