On my LAN I have 2 machines sharing some folders via SAMBA protocols.
OMV server.
A fresh Dietpi install on a Raspberry Pi 3 B. On this machine PiHole is also configured, and it does its job OK on the LAN.
I connect to such machines from 2 possible clients
a) Windows 10
b) Android, by way of the SolidExplorer app
Both clients behave perfectly when connecting to server 1 (OMV)
When trying to connect to server 2 (Dietpi)
Android + SolidExplorer can connect no problem
Windows 10 refuses to connect
A few more notes
While adding a new LAN/SMB connection, the first thing the Android/SolidExplorer app does it to survey the LAN for active servers. Instantly, it lists a 10.10.0.0 server instance, which indeed does not exist on the network. Why?
After a few seconds, server 10.10.0.233 is finally discovered, which is the Dietpi machine. Choose this, put username and password in, BAM, it works.
From the Windows 10 client / myComputer → Add network connection → \10.10.0.233 → quite a long time “looking around” on the network → SAMBA shares are finally shown → give user/pwd → not authorised
For completeness, of course I am pretty sure that the user is the one specified inside the smb.conf file, and its pwd is indeed the one set with smbpasswd -a. Which is indeed the user+pwd which is being used to successfully access from Android.
I think I found a solution, although I am unable to detail exactly where the problem lied.
The laptop in my office helped.
From my company I am connecting back home via a VPN configured on my home router.
Once the VPN is established I can regularly access my home network, with the exception of SMB shares.
Unlike what happened from within the internal LAN (see previous post) when I tried to configure a new remote mount the system did not even show me existing SMB shares, but rather let me wait indefinitely.
Fiddling around, I found out that my business laptop’s main windows LAN profile was under the “Public” category.
Switching to “Private” category solved the problem instantly.
Good, so when I came back home I readily went and checked wether also my home pc had the same “issue”.
No, it did not. My home PC’s network was already tagged as “Private”, and in facts it insisted on being able to flawlessly mount my OMV Samba shares, but not my Diepis’.
No joy then. Until I did one thing: Reboot the pc.
After rebooting, my home pc is finally able to mount Dietpi’s volume.
So as I said in the beginning: the good news is that I don’t have the problem anymore, the bad news is that I have no clue what caused it
Great it solved itself. Possibly Windows Firewall related. I am not 100% sure if there are some auto adjustments done and indeed there are two layers of firewall rules on Windows where I am always not 100% sure which one applies in which case and which interactively and which non-interactively.
10.10.0.0 is usually a place holder for all IPs within 10.10.0.X range. So I guess this is just shown as an indicator that Samba servers within this IP range are currently searched. If you are connected to multiple networks concurrently perhaps every IP range shows up and you can select one to force a Samba server search within the particular network.
By enabling this, the Samba dietpishare can be found and connected with “dietpi” user & password.
It still can’t be found by windows network search (even after reboot), you have to manually enter \dietpi"yoursharedfolder".
Can be found by searching with Android Solid Explorer though !?
Don’t know if this is a good solution, Microsoft says to this:
“By enabling insecure guest logons, this setting reduces the security of Windows clients.”
Searched way to long to fix this, because I thought the fault was on DietPi’s side.
I didn’t have this problem with Samba shares with Open Media Vault and my TPLink Routers Samba service.
Don’t know, what kind of Dietpi samba version or extra commands this is causing not to work with a new Windows installation with default configs. Maybe something like this should be mentioned on the DietPi’s Samba Info page, wondering why not more people had problems with this… Maybe its because of the 1903 windows update, which is relatively new.
