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. ** Changed in: gvfs (Ubuntu Hardy) Status: New => Triaged -- SMB error: Unable to mount location when server configured with security=share https://bugs.launchpad.net/bugs/209520 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs