I spent the weekend diagnosing and fixing a really odd (to me) problem with #Windows machines accessing a #Samba and #Linux -based file server.
I would try to log in to the server when attempting to access the shares (since Windows doesn't like no-authentication network activities -- which is reasonable). I added accounts to the Samba server to try to make it work, and made sure the workgroups and protocols matched. No luck. Tried all kinds of permutations on the logins. No dice. The worst part was it worked, then a few months back, it stopped, seemingly after some updates and settings modifications.
I was convinced it was a problem with network security settings or authentication and systematically investigated each one.
It turned out Windows wasn't happy that I'd mapped network drives persistently, and thought I was trying to establish multiple connections to the same source. So accessing the Samba shares worked once, and I'd mapped drives afterwards. Then it stopped working.
I removed the persistent mappings and wrote a logon script that recreates them each time. Like magic: problem solved.
I will say that this problem took a long time to solve because the behavior was so unexpected. As you can imagine: accessing the shares worked from any account lacking the mappings, and failed where the mappings existed. But it looked like it might be an Azure AD authentication issue, or an admin vs regular user issue...etc.
There was a possible tie in with a security setting, though: I'd disallowed local storage of network credentials (on recommendation from Microsoft). And overall, persistent drive mapping (using the Windows capability to do it) seems to run into problems under such conditions, with no attempt to request new credentials. It just fails and blocks further attempts to access the network resource, until you delete the mappings.
Perhaps there's a further setting that addresses this, but for now, I'm just happy with a working system.
