smbclient can access Windows share content, mount.cifs cannot

Question

I have been given an account on a Windows file server. The (to me) very strange situation is that

• I can connect with smbclient, change to the (deep) subdirectory or show its content
• I can mount the share (no error message; mount point is in /proc/mounts) but I cannot change to the same path or list its contents. I get No such file or directory.

I have neither "display content" nor "change into" permission for the lower level subdirectories. That should not be a problem and it is not for smbclient.

The Windows admin has given my user additional permissions so that I can now see contents of the moint point. And now I can reach the deeper level subdirectories via the mount, too.

We have not determined yet what the minimal set of Windows permissions is which we need for this to work in the current configuration. However, the problem must be on the Linux side anyway.

• What are the differences between the ways how smbclient and mount.cifs access a Windows share?
• How can mount.cifs be made to behave like smbclient?

conclusion

I had the Windows admin reset the permissions of the share so that I could test the suggestions in the answers. Unfortunately the problem disappeared. As before I cannot see the contents of the share but now the mount can access the deep subdirectories. Very strange.

A remark @intika: I was going to make an additional bounty for your answer but while I was doing so you for some reason deleted your answer...

responses to comments and answers

Windows server

Server 2016, SMB 3.1.1

Samba version

4.5.16; not a member of the domain

commands used

• /etc/fstab: //fs-p01.dnsdomain/Data /data cifs credentials=/root/fs-p01.credentials 0 0
• smbclient //fs-p01.dnsdomain/Data -U username -W windowsdomain

I just realize that windowsdomain in the smbclient command was incomplete. Probably not relevant as this works. It was just name instead of name.local. However, that is a difference in the configuration between the commands. Unfortunately I cannot check whether mount would work if I use the wrong domain with it as I cannot change the permissions on the Windows server back to their original settings. I have to wait for the Windows admins to do that on Monday.

paths

The path length within the share is 85 characters for the directory I want to work in. I should be able to access its parent, too, i.e. even less:

xxxxxxxxxxxxxxxxxxx/xxxxxxxxxxxxxxxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/2020/2020_06

config files

/root/fs-p01.credentials

username=username
password=...
domain=name.local

/etc/smb/smb.conf (probably not relevant for client functions)

[global]
   workgroup = MERCHANTINVOICE
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   # panic action = /usr/share/samba/panic-action %d
   server role = standalone server
   passdb backend = tdbsam
   encrypt passwords = yes
   unix password sync = no
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = no
   map to guest = bad user
   usershare allow guests = no

Answer 1

As intika has indicated in the comment you did not give us enough details.

Path limitations

You maybe hitting the infamous 260 Maximum Path Length Limitation. There is an Unicode way to access the API, which has a 32,767 limitation. In windows world it depends if you are accessing it as \\server\share (the 260 limit applies) or \\?\UNC\server\share (the 32767 limit applies).

Now question is, how long is your path which you want to list. The second question is which smbclient is using vs. mount.cifs.

Quoting from the smbclient man pages:

smbclient supports long file names where the server supports the LANMAN2 protocol or above.

Whereas I could not find anything mentioning mount.cifs supports long path so for now it is safe to say mount.cifs does not support long path.

SMB protocol version

I presume you are not using smb1 as it is considered unsafe.
Are you using smb2 or smb3 to connect smbclient/mount.cifs?

There maybe NTLM security implications if you are using smb3 protocol, which could prevent you listing the directory.

Note: you should check the log (event viewer) on the server not on the client, to see what is going on.

Edit: due to the update and comment

I think you may suffer from the dot smbv2 bug (when using mount).
Which in short is:

When mounting a Windows share that is the root of a drive (eg. C$) the server does not return . and .. directory entries. This results in the smb2 code path erroneously skipping the 2 first entries.

How to find it out? You can specify in your /etc/fstab entry the smb version which should be used by adding e.g. vers=3.0 (smbv3). I would approach the problem by, if possible (if supported), downgrading the version to vers=1.0 to see if everything is shown.

So your mount code would look like this (I have added also sec to enforce the ntlm (you may have to try other which you may find in the mount.cif man pages :

//fs-p01.dnsdomain/Data  /data  cifs  credentials=/root/fs-p01.credentials,vers=1.0,sec=ntlm  0 0

If smbv1 is disabled and you can't enable it for testing purposes you can enable SMB debugging by using:

echo 1 > /proc/fs/cifs/traceSMB

You would then do simple ls -la to see if you can see the directory in the log. If yes, you are influenced by this bug.

Third option that comes into my mind would be to have more than 2 entries at the mount root. Those should start in a way that they should be before the entry(ies) you want to see.

The reported bug

This bug has been reported already. You can find it at samba's bugzilla

Solution

You could try to use this patch by Aurelien, but I don't know if it was properly tested.

Second option is to do a "workaround" similar to the third option above. Have two directories that would be on the top with default sorting. This is just a quick workaround. It should really be patched in order to have proper fix.

Answer 2

Server Side

You may consider the server side as well, we know it is a Windows share, but nothing more, it would help to know the windows and SMB version this particular case is using. The server configuration can make a big difference especially when not using the Windows OS as a client. You know, ever since the windows shares appeared, it has been a game of cat an mouse, with the Samba and other teams chasing the changes implemented by Microsoft, since it is a closed system, they are not compelled at all to disclose the new features.

Main differences

What are the differences between the ways how smbclient and mount.cifs access a Windows share?

smbclient was meant to be used as a command line utility to have access to a network resource, mount.cifs is normally used by root, invoked by the mount command when using a cifs filesystem type, when used in the /etc/fstab file it is used to have permanent access to a filesystem.

From the man page The main difference may be that mount.cifs ignores smb.conf completely

samba client tools like smbclient(8) honour client-side configuration parameters present in smb.conf. Unlike those client tools, mount.cifs ignores smb.conf completely.

smbclient is an old implementation of an old protocol, SMB was replaced by CIFS, supposedly, cifs has the considerations for a newer implementation.

So, it may be a good idea to use a recent implementation of the protocol, but you should check which of these implementations works better with the server version available.

Can they behave the same?

How can mount.cifs be made to behave like smbclient?

Since mount.cifs ignores the smb.conf file, all the configurations of such file should be expressed in the invoking command, say, the corresponding line in /etc/fstab. For instance, you are already considering the -U username option used in smbclient, but there are other configurations in the smb.conf thay you may check. Particularly the log configuration, where the error messages may be written, should be that one of the fstab file, not the smb.conf file, check dmesg, /var/log/boot, /var/log/messeges