Samba share enumeration doesn't work anymore

Operating system: openSUSE Tumbleweed 20220408
Samba version: samba-4.16.0+git.224.70319beb8f8-1.1.x86_64

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?

I have noticed the same problem.

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”.

This upstream bug report may be of interest to you…

Thank you!
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.

I posted the question on the mentioned bug thread.

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!

Same problem here. In fact I have gone back to Leap 15.3 because I need access to my Windows shares.

I installed the latest (4/20) Tumbleweed snapshot and the problem persists there.

To be precise, I am using the KDE desktop and therefore Dolphin to access the shares. When I try to access them, I am still told something to the effect that the shares don’t exist.

I saw that the last comment on the bugzilla thread about this claims “FYI: KDE is not affected!” This is not true, at least from my experience.

I did not think it worthwhile, however, to make an account on bugzilla just to make a rebuttal.

Enumeration is working again on my machines with
“openSUSE Tumbleweed 20220420 - Kernel 5.17.3-1-default x86_64”

For me the problem persists. I access my shares through Dolphin (smb://). Still getting the “file or folder does not exist” reply.

No problem on Leap 15.3 which is at samba version 4.15.4+git.324.8332acf1a63-150300.3.25.3.

Apparently now the problem only exists on KDE?

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.

Still no luck here, even with all the permutations you suggested, although I appreciate the help.

I’ll just stick for now with Leap 15.3, which is no tragedy. TBH I hardly notice any difference.

And sometimes the daily updates with Tumbleweed get a little tiresome anyway.


I get the same behaviour in KDE/Dolphin, Plasma. Using smbclient works fine.

TW as of yesterday.
samba 4.16.1+git.237.1d04c5f421f-1.1
dolphin 22.04.1-1.1

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.

More details are at the last posts in*?p=3130649#post3130649

Kind regards,


PS: smbclient -L works ok for me, so maybe similar but not the same…

Perhaps using Leap 15.3 (or 15.4) with a recent stable kernel might be an option…

OK. I’ll try to install Leap 15.4 in two or three months, then note the result here.
Meanwhile I can work with samba in a terminal using smbclient. Mounting (as root) via

mount -t cifs -o <windowsusername> -p=<windowspassword> //windowslaptopname/windowssharename /run/media/mysharename 

also works.

Hello flo37,

If you still want to access the files via Dolphin and until a patch is provided from KDE ( 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

  • smb://<server>
  • smb://<server>/<share>

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)

  • smb://<username>:<password>@<server>
  • smb://<username>:<password>@<server>/<share>

So as an example:

  • smb://myself:verysecurepasswort1234@mynas
  • smb://myself:verysecurepasswort1234@mynas/myshareddirectiory

Hope this helps you or others