Comment 111 for bug 209520

In the end, the explanation for being unable to connect to servers using share-level security is very straightforward. If I configure a samba server here for security=share and connect with smbclient, I see the following:

$ smbclient //borges/pub
Password:
Domain=[DNSG] OS=[Unix] Server=[Samba 3.0.30]
Server not using user level security and no password supplied.
Server requested LANMAN password (share-level security) but 'client use lanman auth' is disabled
tree connect failed: SUCCESS - 0
$

The use of lanman authentication has been disabled on both client and server in Ubuntu 8.04 because it's substantially weaker that NTLM passwords, and therefore more vulnerable to decryption attacks of the network traffic. To be precise, the man page for smb.conf says:

          This parameter determines whether or not smbclient(8) and other
          samba client tools will attempt to authenticate itself to servers
          using the weaker LANMAN password hash. If disabled, only server
          which support NT password hashes (e.g. Windows NT/2000, Samba,
          etc... but not Windows 95/98) will be able to be connected from the
          Samba client.

          The LANMAN encrypted response is easily broken, due to it’s case-
          insensitive nature, and the choice of algorithm. Clients without
          Windows 95/98 servers are advised to disable this option.

          Disabling this option will also disable the client plaintext auth
          option

I didn't remember that share-level security was restricted to lanman password authentication, but now that I see that, this failure to connect makes sense. It is not accidental that the client refuses to negotiate security in such a situation; I still believe this is the correct default for libsmbclient to use in hardy, because enabling weak authentication in the client doesn't just make it possible to use older servers, it also makes it possible for a man-in-the-middle attacker to trick your client into using weak authentication when trying to talk to a newer server, compromising other passwords in the process.

As a workaround, users who need to access security=share servers can add 'client lanman auth = yes' to the [global] section of /etc/samba/smb.conf on their hardy client systems, to enable negotiation of this weak authentication protocol.

For nautilus/gvfs, there definitely should be a better feedback mechanism about this problem, so that users get some indication of why the connection has failed.