How do I check if wsdd2 is actually running ?
I only know that it is installed:
oh, that error is pointing to samba36/4 or ksmbd not running at that time.
"wsdd2: samba36/4 or ksmbd is not running" There's a problem. Idk this needs expertise knowledge and experience. As of now I can't help much on this 
In mean time I suggest just start clean, install only luci-app-samba4 and make the changes I showed.
Okay thx, although just quickly looking through their fix doesn't seem to apply to me as my interface name is no longer br-lan, it's lan, and they want changing "network_get_device ifname lan" to "network_get_device ifname br-lan".
I had to install USB drivers for my second nic as the wan....and another not so problem it doesn't show my other interface such as eth1(usb) in the port status overview, but everything else seemingly works, pppoe over vlan, SQM QOS, openvpn server, dynamic DNS a bit iffy, doesn't detect IP changes on reboot or reconnect of PPPoE, but eventually does.
I will try clean though......tomorrow...need to get some sleep 
1 Like
Just to add another one Windows 11 registry edit things to disable
new to Windows 11 is disabling the RequireSecuritySignature
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v "AllowInsecureGuestAuth" /t REG_DWORD /d 0x1 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v "RequireSecuritySignature" /t REG_DWORD /d 0x0 /f
Had the same issues. https://www.syxsense.com/syxsense-securityarticles/cis_benchmarks/syx-1033-12369.html did the trick.
If it's the typical issue then the easiest workaround is to change your Windows account from Microsoft to 'Local'. Nothing prevents you from using a password with a local account.
Edit: oops, meant to reply to OP, not to @AlanDias17
I had a similar issue, to get my OpenWrt shares working with Windows 24H2 Professional
I used gpedit to edit my PC's group policy:
Computer configuration:
Administrative Templates > Network > Lanman Workstation
=> enable 'Enable insecure guest logons'
Thx for the help guys,
I didn't want to regedit every single Windows client so I just ended up virtualising openwrt inside of proxmox, and then adding a virtualised Openmediavault host with samba service enabled. It works better, maybe not faster though.
Nice workaround. If you want, then just punching in some commands to tweak the registry works too. I don't actually run Windows 11 Home, so I dug up some links that could help you 
https://www.reddit.com/r/Windows11/comments/1kevwrh/defeated_home_network_sharing/
Accessing a third-party NAS with SMB in Windows 11 24H2 may fail | Microsoft Community Hub
1 Like
The root cause of the Samba problem mentioned in the opening post is an outdated Samba config. Using all those Windos registry keys lowers security to 30-35 year old Standards.
I cannot fully advise on this within OpenWRT known configs, as I an not using the simplified OpenWRT Samba wrapper config fles. I have switched to using the regular Samba config file Standard on my OpenWRT device (as this also allows more fine Samba config options, like enabling the Samba recycle bin)
With all those server and client options mentioned in this thread, you are basically not setting up or fixing Samba, just lowering the fileshare security to 30-35 year old Microsoft standards. Instead of lowering the client security, you can also raise the Samba service security config.
Both will of course work, but lowering the security is also additional config work on each client and you effectively operate Samba shares in 35 year old mode, in Windows 3.1 workgroup mode. Some of thesettings are like setting no password on OpenWRT root, any malware or actor in your local network will get unauthenticated full Access to all your files.
None of thes lowering is needed, but unfortuantely I do not know, if this can be achived with the simplified OpenWRT samba config file (and I do not have a test environment to test it right now).
You can use a different Samba config, to avoid having to set all those downgrade registry keys. Better security and less effort patching each client is the result.
what the mentioned reg keys do:
- allowinsecureGuestAuth effectively enables a credentialfree mode, where you neither need username and Password, to Access a share. The share is just open for anyone.
- LmCompatibilityLevel enables Windows clients to use 35 year old weak LM authentication, if requested by a server. You would need this, to allow Win3.1 Client to access your Samba share.
- RequireSecuritySignature. If you set this to 0, hell will not break loose, as ist just a package signature, not an encryption. But Samba does support it, so ist actually not needed to disabling it. If your Samba access does not work without disabling it, ist a clue that you are using a Samba config file in mode "security=share", which is the Samba-way of Windows Workgroup mode (which is also like 30 years old). In this mode, Samba does not support signature.
If you instead switch the Samba config to "security=user", you do not need to disable this mode on the client. - Windows 11 23H2 and 24H2 had default-raising more and more of these security settings. If you upgrade an older version, it even takes over most older weaker Windows default configs, while the higher Settings are set, if you install Windows11 24H2 from Scratch.
But I do not know, if the simplified OpenWrt Samba config supports this at all.
Of course, it could be that you purposely want to disable username and Password for convenience or do have Windows for Workgroups 3.1 clients (but that is like disabling the password for OpenWRT root for convenience reasons, any malicious malware or actor in your network will have immediate Access to all your files).
I think is important to mention for non-IT-aware users reading this thread, that these registry settings are not necessarily required for Samba usage. You need them, if you want to lower the bar a lot or want to use ancient Windows clients or probably you just want stay within the perimeter of the simplified OpenWRT config options. I do very well understand that some People want to stick to the shortened OpenWRT samba config file and just get things up and running.
But I want to point out that the Samba config style of OpenWRT seems probably a bit outdated or limited, if setting those reg keys is required. And that users end up in a less then ideal home security config, if following all recommendations of this thread.
(I can post my smb.conf later, in case anyone is interested)
2 Likes
The whole Samba setup supposed to be simple and straightforward, as the guides suggest. Install the required packages, mount your drives to a designated mount point, make a few minor adjustments to the Network Shares configs and done. For most everyday users, the default settings are perfectly adequate.
However, OP is encountering a specific issue with Windows 11 Home. Samba is working for all other devices, including Android and Mac. I suspect a recent Windows 11 update might be the culprit, one of the links I previously shared seems to corroborate this. I'll post here YT link for those who prefer a visual walkthrough Setup Network Share (Samba) on OpenWrt | Step-by-step tutorial
2 Likes
Since Windows 10, if Microsoft account is used (rather than local account), trying to connect to a Samba share normally fails exactly the way it's failing for the OP. So I'll repeat what I wrote above: the first and easiest thing to try is using a local account. The OP could create a new local account and test with it.
I should say I have always been using a local account. It was a fresh install of Windows 11 Home and I used Rufus to force local account creation. All other PCs were Home with local accounts.
I think I also might have tested with 11 LTSC version as well.
Then my next best guess is directory permissions issue. It is possible that the shared directory's permissions are not set correctly, and Windows guests handle this differently than Linux and MacOS guests.
Hi
As a recent convert to Win11 (because Win 10 is going EOL), there are a few things that were different vs the older windows versions.
As always, Windows craps out every once in a while. Doing a network reset is a way of life with Windows.
Connecting to my debian based NAS/Samba 4.22, Windows 11 needed the SMB3 options added to the .conf file
[global]
workgroup = WORKGROUP
netbios name = XXX
veto files = /.?*/
client min protocol = SMB3
server min protocol = SMB3
oplocks = no
level2 oplocks = no
Give it a try.
I'm not sure how to check this
I added this and it still doesn't doesn't work, but now Android client isn't working as that it seems was using SMBv2
Ok, from looking at the error code again, and then searching google + together with finding another page mentioning client/server min protocols I found another 2 options to add which worked. For me I didn't need client/server min protocol. I just needed the 2 in the screenshot, or at least I think I do. I didn't test with one or the other, but it works now in all my Windows clients and Android since I didn't use min protocols as SMB3.
I found the info from here https://www.reddit.com/r/sysadmin/comments/b3ndqy/windows_server_2019_cannot_access_smb_share/
edit: After having to redo my OpenWRT installation it didn't seem to work, but I tried commenting out that "map to guest = Bad User" option mentioned in the link and it started working, even though I had that disabled and then re-enabled before........or a system reboot made it work....unsure.
edit2: After commenting out or removing entirely my supposed 2 lines fix:
#restrict anonymous = 2
#encrypt passwords = true
and only commenting out:
#map to guest = Bad User
and a reboot: It seems only that bad user option was the problem and commenting out is the fix.
Perhaps if this is true, then maybe the way Windows handles things, is it tries to access a share as a guest firstly, and then when it cannot it tries a user acccount.....but if this map to guest bad user option is enabled then Windows can never try a user account/login method since it just probably blocks Windows from seeing the share entirely.
1 Like