After updating samba to 4.16.0 the listing of “smbclient -L //sambaserver” is empty and access to “\sambaserver” from Windows 10 clients is showing “access denied”.
Access to shares via “smbclient //sambaserver/share” or “\sambaserver\share” from Windows ist still working as before.
The configuration wasn’t changed since 4.15, which was working normally.
Is this a regression or could it be a missing change to my configuration files?
Probably related is that, when trying to access my own shared folders over the network, I am asked for a username and password. It then rejects my own username and password and I am then told “Access denied”.
As far as I understand the description of bug 14983, they change of the error return value is causing a problem with libsmbclient and nautilus not handling the error right.
But Windows now also is not able to list the shares for anonymous and authenticated users with Samba 4.16.
Samba-Bug 14983 was closed because of a patch to gnome, not samba, that resolved it.
So it seems that was something different to my problem.
Is it true that I’m the only one experiencing this problem?
And that’s so on all of my machines - strange!
I tried “smb://” in Dolphin, which leads to “No shared folders were found”, which is correct as SMB1 is deactivated.
With “smb://sambaserver” I get the list of shares on this server successfully.
With “smb://sambaserver/share” Dolphin shows the contents of that share successfully.
Perhaps you should try to update samba again, even if there is no change in the release date of Tumbleweed.
I get the same behaviour in KDE/Dolphin, Plasma. Using smbclient works fine.
TW as of yesterday.
Unfortunately, I can’t test an older version on this brand new laptop (Leap 15.3 can’t discover the harddisc with the new intel chip set, and I am afraid to mix an older samba with the current TW). So I can’t be sure it’s the same issue, but the result looks alike.
If you still want to access the files via Dolphin and until a patch is provided from KDE (https://bugs.kde.org/show_bug.cgi?id=453090) and backported from SuSE, you must provide the credentials upfront, instead of waiting for the login prompt. Reason is, to prevent that the error is raised about a wrong login. At least for me that solved the problem.
So instead of
you must already provide your username **and **password (good to know, the password will be removed from the URL after sending the URL, drawback, the password is at least displayed while entering it)