Regression in smbclient, username required for anonymous login

[Clement Lefebvre]

I noticed a regression in smbclient between 16.04 and 18.04.

After setting up an open share (RW access to everyone, no password) on the Windows 10 box, I can access it with Ubuntu 16.04 (samba 4.3.11):

$ smbclient -L 192.168.0.104 -N
WARNING: The "syslog" option is deprecated
OS=[Windows 10 Home 17134] Server=[Windows 10 Home 6.3]

 Sharename Type Comment
 --------- ---- -------
 ADMIN$ Disk Remote Admin
 C$ Disk Default share
 IPC$ IPC Remote IPC
 MySharedFolder Disk
 print$ Disk Printer Drivers
 Users Disk
Connection to 192.168.0.104 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
NetBIOS over TCP disabled -- no workgroup available

I get that successful result also if I set the min protocol to NT1, SMB2 or SMB3 using the -m argument.

But if I try to access it in Ubuntu 18.04 (samba 4.7.6), I get an ACCESS_DENIED error:

$ smbclient -L 192.168.0.104 -N
WARNING: The "syslog" option is deprecated
session setup failed: NT_STATUS_ACCESS_DENIED

Specifying the protocol to SMB2 or SMB3 doesn't change anything:

$ smbclient -L 192.168.0.104 -N -m SMB2
WARNING: The "syslog" option is deprecated
session setup failed: NT_STATUS_ACCESS_DENIED

Interestingly enough, changing it to NT1 doesn't solve the issue but note how smbclient reports a successful anonymous login:

$ smbclient -L 192.168.0.104 -N -m NT1
WARNING: The "syslog" option is deprecated
Anonymous login successful

 Sharename Type Comment
 --------- ---- -------
Error returning browse list: NT_STATUS_ACCESS_DENIED
Reconnecting with SMB1 for workgroup listing.
Connection to 192.168.0.104 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Failed to connect with SMB1 -- no workgroup available

And finally, what solves the issue is to set a username to something, anything. In the example below I use the string "dummy", which doesn't correspond to any username in the Windows or in the Linux box:

smbclient -L 192.168.0.104 -N -U dummy
WARNING: The "syslog" option is deprecated

 Sharename Type Comment
 --------- ---- -------
 ADMIN$ Disk Remote Admin
 C$ Disk Default share
 IPC$ IPC Remote IPC
 MySharedFolder Disk
 print$ Disk Printer Drivers
 Users Disk
Reconnecting with SMB1 for workgroup listing.
Connection to 192.168.0.104 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Failed to connect with SMB1 -- no workgroup available

[Clement Lefebvre (clementlefebvre)]

This is observed when connecting to shares using the UI also. When gvfs launches the auth dialog, selecting to connect anonymously fails and results in the dialog appearing again. A successful connection can be achieved by typing a dummy username and a dummy password instead.

[Clement Lefebvre (clementlefebvre)]

I can reproduce the issue on 18.04 with smbtree as well:

$ smbtree -U dummy
WORKGROUP
 \\STORM
  \\STORM\Users
  \\STORM\print$ Printer Drivers
  \\STORM\MySharedFolder
  \\STORM\IPC$ Remote IPC
  \\STORM\C$ Default share
  \\STORM\ADMIN$ Remote Admin
 \\AIRTOP airtop server (Samba, Ubuntu)
  \\AIRTOP\HP-ENVY-5540-series HP ENVY 5540 series
  \\AIRTOP\IPC$ IPC Service (airtop server (Samba, Ubuntu))
  \\AIRTOP\print$ Printer Drivers

$ smbtree
WORKGROUP
 \\STORM
 \\AIRTOP airtop server (Samba, Ubuntu)
  \\AIRTOP\HP-ENVY-5540-series HP ENVY 5540 series
  \\AIRTOP\IPC$ IPC Service (airtop server (Samba, Ubuntu))
  \\AIRTOP\print$ Printer Drivers

$ smbtree -U dummy
WORKGROUP
 \\STORM
  \\STORM\Users
  \\STORM\print$ Printer Drivers
  \\STORM\MySharedFolder
  \\STORM\IPC$ Remote IPC
  \\STORM\C$ Default share
  \\STORM\ADMIN$ Remote Admin
 \\AIRTOP airtop server (Samba, Ubuntu)
  \\AIRTOP\HP-ENVY-5540-series HP ENVY 5540 series
  \\AIRTOP\IPC$ IPC Service (airtop server (Samba, Ubuntu))
  \\AIRTOP\print$ Printer Drivers

In the example above, STORM is the Windows 10 box, AIRTOP is another Linux box. Note how STORM is visible with or without username, but its shares only appear when a username is given.

[Clement Lefebvre (clementlefebvre)]

Small mistake in the previous comment, AIRTOP is the local Linux box.

[Andreas Hasenack (ahasenack)]

Are you able to try with a newer samba version, preferrably the one in disco, which is 4.10? Booting from a disco pendrive and installing smbclient should be enough.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Clement Lefebvre (clementlefebvre)]

Hi Andreas,

I'll try in live mode and let you know.

[Clement Lefebvre (clementlefebvre)]

Hi Andreas,

19.04 disco amd64 in live mode with smbclient 2:4.10.0+dfsg-0ubuntu2 added: I can't reproduce the issue there, it works well without a username.

"smbclient -L 192.168.0.104 -N" lists the shares successfully. Specifying a dummy username works also, but isn't necessary.

[Andreas Hasenack (ahasenack)]

Good to know. Now to find out what the fix was between 4.7.6 and 4.10...

[Clement Lefebvre (clementlefebvre)]

I can try the cosmic version live as well early next week if it helps, it's 4.8.4.

[Andreas Hasenack (ahasenack)]

It does, thanks a lot!

[Clement Lefebvre (clementlefebvre)]

Hi Andreas,

Same result in Cosmic. With smbclient 4.8.4, "smbclient -L 192.168.0.104 -N" lists the shares successfully. Specifying a dummy username works but isn't necessary.

[Robie Basak (racb)]

That's useful, thanks. I think we need to identify the fix, somewhere between 4.7.6 and 4.8.4. This task is in our backlog but I don't think we'll get to it any time soon. If someone can help with this task, please do.

[Clement Lefebvre (clementlefebvre)]

Hi Robie,

Looking at the samba changes upstream, the series of commits merged on the 4.7 branch on March 20th 2018 look extremely relevant:

https://github.com/samba-team/samba/commits/v4-7-stable?after=b7d190f89d7674cf58a02486fa9887d393918611+304

They come immediately after 4.7.7, which doesn't bump tevent/talloc. Could we cherry-pick the 4.7.7 and March 20th 2018 commits?

[Sebastien Bacher (seb128)]

Is that still an issue in 20.04?

[Andreas Hasenack (ahasenack)]

No, comment #8 shows disco is already fixed. This may be SRU material for Bionic.