I"m unable to access my ksmbd network share on my primary router, a TP-Link Archer C7 v5 running 21.02.3. It was working fine on 21.02.2 and continues to run on my 21.02.1 TP-Link TL-WDR4300 v1. The usb drive is mounted and I can browse it within openwrt; ksmbd appears to be configured correctly, and wsdd2 ... well that's another story.
On the working device, netstat -tunlp shows a bunch of ports open by wsdd2, and a wsdd2 process running.
On the not-working device, no wsdd2 ports, no wsdd2 process. Start / Restart of wsdd2 via luci's Startup page was failing until I started it manually via cli; and of course I didn't note down the error message. Uninstalling wsdd2 produces an error: Not Found. I also tried reinstalling wsdd2 via the opkg command line with the same results. /usr/bin/wsdd2 exists on both devices, though, and luci shows wsdd2 as installed.
If I manually start wsdd2, it starts, but with some errors I don't know what to make of:
cannot read additional dns hostnames from testparm
cannot read netbios name from testparm
cannot read netbios aliases from testparm
cannot read workgroup from testparm
'testparm' appears to be a samba4 utility; I don't have samba4 installed on either device.
Once wsdd2 is manually started, I can see my router in Windows File Explorer, but can't access it, and don't see my share.
w2dd2 won't work correctly if your interface is set to dhcp
has not worked since DSA was introduced v19 = ok v21+ = not
you could try to set the IP statically but well
ksmbd has it's own problems it was working under V21.02 then a versoin got back dated & broke it & V21.03 it may still be broken
I recommend samba4 if you have the space & do try a few times
dsa and ksmbd are orthogonal features and not related to each other. This is particularly easy to prove, as ath79 (the target for both of the devices owned by the OP) isn't even using dsa, yet.
I didn't say DSA was the cause of ksmbd
just that between V19 & V21 wsdd2 stopped working if the interfaces set to dhcp
around the time all devices got rearranged for DSA
you know when the Device menu appeared under Interfaces on all devices
Correlation still does not imply causation, provably so in this case (no dsa at all on these devices).
ksmbd has 'just' been merged into the mainline kernel, as part of the review for the kernel parts, quite a few changes were necessary (as this is the last opportunity to get things right, before the userspace ABI is cast in stone). Changes, even if they are strictly for the better, imply disruption - and disruption can affect the compatibility of the (now) in-kernel parts with its supporting userland. In previous releases, this was 'easier', as both userland and kernel modules were released together (and in their own cadence, instead of racing for their first merge window), naturally in-sync (but at the expense of being an out-of-tree distribution, with all the problems -including quality- that entails). The changes will massively improve ksmbd in the medium term (and are required to start depending on it), but in the short term, development can be a little more volatile than before.
--
Rule of thumb: it takes around at least three kernel releases (minor, not -stable/ EXTRAVERSION/ micro) in-tree, before a newly merged driver has lost its quirks and warts in order to be considered reliable for the userbase at large, outside the lab.
Thanks for the info! Having moved ad block to another device, I should be able to swing samba4. I'll give that a try in the interim, but as I like the promise of ksmbd I'll keep tabs on it.
