[linux-cifs-client] system haven't been able to cifs mount a share that I don't have rights to.> As I said in my mail of 7th March, I can "mount -t smb" a share that I have > no rights to; however I cannot "mount -t cifs" the same share. IRe: Mounting directories below share level

[Steve French]

>  
> system haven't been able to cifs mount a share that I don't have rights to.
> As I said in my mail of 7th March, I can "mount -t smb" a share that I have 
> no rights to; however I cannot "mount -t cifs" the same share.  If I set 
> cifsFYI to 1, I get the attached information logged through syslog.  I 
> assume, naively, that it is the cifs_read_inode that generates the 
> ACCESS_DENIED error.

Your assumption seems reasonable that the access denied is on the lookup
of the root directory of the share (this lookup is done at the end of
mount by the kernel).  It may be that smbfs masks errors on 
lookup of the root directory of the share.  In my tests (from CIFS to
Windows) I saw empty directories on ls but not access denied IIRC -
we really need to trace smbfs vs. cifs for the two mounts. If they
end up validating properly with the same user - it may turn out
that smbfs ignores the QueryPathInfo return code in this particular
case.   A small ethereal trace of each of the two mounts would be
useful to see if smbfs is also getting access denied on QPathInfo
as well - or if smbfs is using a backlevel call (like the old
DOS style SMB getattr) and the server is not consistently setting return
codes on that the same as the newer equivalenet (Transact2 QueryPathInfo
FILE_ALL_INFO

> Just to save going back up the thread, the command I tried was:
> 
>  mount -t cifs //ip.address/UserShare1$ /mnt -v -o 
> user=test,pass=******,netbiosname=ma
>  
> As the mount appears to have been OK, can I stop cifs trying to access the 
> share after mount?
Not that I can think of - the kernel is the one doing lookup on '.'
>   I tried -o noserverino but it comes back as an unknown 
> option.
noserverino mount parm was introduced after 2.6.9 kernel with the 1.24 version 
of cifs vfs (current is 1.28 in 2.6.10, and 1.30 in mm tree and the cifs 
bitkeeper tree), but I would not expect that noserverino would make much
difference here (not just because noserverino already is the default, but because 
the failing call is used to find the type of the inode - whether file or directory e.g.).