[linux-cifs-client] Mounting CIFS gives me permission denied

[Steven French]

Some explanations as to what is going on.

1) smbclient -L (without specifying the domain) works because smbclient 
supports signing as well as both kerberos and ntlmv2 and the default 
domain is good enough
2) "smbclient -L 192.168.1.2 -U na/HOMEXCORP" fails (probably) because 
your domain name and user name are backwards in the -U
3) smbmount (smbfs) fails because it doesn't implement signing (which is 
one of the reasons that I wrote cifs vfs in the first place, to add to the 
kernel, enough code to do security functions such as signing, rather than 
relying on userspace smb client libraries which are awkward to get at when 
processing every frame)
4) mount -t cifs probably fails because the server is configured so that 
either
        a) Kerberos is required (CIFS SPNEGO implementation is not 
complete so can not handle 
        kerberized session setup - yet)
                or
        b) NTLMv2 is required (CIFS support for NTLMv2 is turned off by 
default in /proc/fs/cifs/ 
        because AFAIK it is not well tested)
                or
        c) plaintext paswords or old lanman password hashes are required 
(these are too insecure - and 
        the cifs vfs will refuse to negotiate them)
                or
        d) your client's hostname (but not the ip address) is explicitly 
allowed in the workstations 
        allowed list on the server but the cifs vfs does not send the 
client's netbios name unless 
        you connect via the older netbios-over-tcp port 139  (and 
"netbiosname=workstation_name" 
        was not passed over -o on the client mount).
                or 
        e) that share can only be mounted by administrators not by the 
user that you tried

We might be able to rule out 4b (NTLMv2 required) if extended security 
were enabled in /proc but this will only work to WindowsXP and 2000 
clients - or servers not in a domain - since they will then negotiate "raw 
ntlmssp" which cifs does support rather than spnego which it does not). 

In any case tracing on port 445 and 139 is quite similar and it does not 
much matter which end you trace on there are similar tools available on 
each.

Also note that if this is a windows server they have an audit or security 
event log (I forget what it is called) which may tell you what is going on 
- see System Tools -> Event Viewer -> Security on the server if it is a 
windows server - obviously with Samba you have more detailed info you can 
get by looking at log.smbd

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
-------------- next part --------------
HTML attachment scrubbed and removed