Why can't Linux see Windows 10 shared files, but can create and delete...?

Question

I've mounted a Windows 10 share with cifs in Debian-stretch with cifs-utils version 2:6.7-1 Kernel 4.15

In Windows I've given the user full permission and full control/access in the sharing and security tabs, and I've done the whole "Replace entries on child objects" etc thing also, and the user is a member of administrators anyway.

FROM LINUX

I can write files into the share, but ls -la can't see any files/dirs other than System Volume information. But some files show up. For example: touch cantseethis; echo "I can see this" > test.txt;

I CAN also delete any file that I can't see: rm fileIcantSee works. All the files written into the share from Linux, show up and work fine in Windows 10.

I mounted it like this: mount -t cifs //windows-10-puter/D /mnt/windows-10/D -o username=bob,password=SECRETSTUFF,noexec,uid=101001,gid=101001

I can mount with the option vers=3, makes no difference. If I try mount with vers=3.1.1 I get

mount error(11): Resource temporarily unavailable
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

If I mount with vers=3.0 or vers=3 or vers=2.0 it will mount but the issue does not change. I tried mounting with vers='1.0' but it said

mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

• I did enable the low-grade encryption options after vers=3 and vers='2.0' didn't resolve the issue, in an attempt to try vers=1.0 but as above it didn't connect at vers='1.0'

This is on a newly formatted virtual disk.

# cat /proc/fs/cifs/DebugData
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 2.10
Features: dfs fscache lanman posix spnego xattr acl
Active VFS Requests: 0
Servers:
Number of credits: 33
1) Name: 192.168.122.104 Uses: 2 Capability: 0x300047   Session Status: 1   TCP status: 1
    Local Users To Server: 1 SecMode: 0x1 Req On Wire: 0
    Shares:
    0) IPC: \\windows-10-puter\IPC$ Mounts: 1 DevInfo: 0x0 Attributes: 0x0
    PathComponentMax: 0 Status: 1 type: 0 
    Share Capabilities: None    Share Flags: 0x30

    1) \\windows-10-puter\D Mounts: 1 DevInfo: 0x20020 Attributes: 0xc706ff
    PathComponentMax: 255 Status: 1 type: DISK 
    Share Capabilities: None Aligned, Partition Aligned,    Share Flags: 0x0    Optimal sector size: 0x200

    2) \\windows-10-puter\C Mounts: 1 DevInfo: 0x20020 Attributes: 0xc706ff
    PathComponentMax: 255 Status: 1 type: DISK 
    Share Capabilities: None Aligned, Partition Aligned,    Share Flags: 0x0    Optimal sector size: 0x200

    MIDs:

Interesting, I did this

echo "foo" | tee 1 2 3 which created files 2 and 3. But when I did ls afterwards, suddenly now I can see EVERYTHING. So weird. The problem seems to be gone. Maybe it's a samba bug that happens on very empty/new disks. I've deleted files 2 and 3 and it's still working now...

Answer 1

This is probably a bug in your version of the Linux kernel. At some point, its SMBv2+ client had a bug where it would skip 2 directory entries under the expectation that they were the virtual . and .. entries; however, since the volume root on Windows doesn't have these entries, it was skipping real files instead.

This commit fixing the problem is present in kernel 4.19.0:

commit 0595751f267994c3c7027377058e4185b3a28e75

    smb2: fix missing files in root share directory listing

    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.

Kernel 4.19 is present in stretch-backports, so you should upgrade. Alternatively, kernel 4.9 in stretch has also received this fix in 4.9.132.

(On the other hand, 4.15 was neither an official LTS kernel nor a Debian "stable" kernel, and its development stopped in April 2018. It will not be fixed unless you do it yourself.)

Note that the Linux kernel's SMB/CIFS client (including cifs-utils) is not Samba and this is not a Samba bug, so merely upgrading smbclient will not solve this problem.

---

You get "Host is down" because the Windows system does not have a SMBv1 server installed. (Windows 10 automatically uninstalls SMBv1 support if it detects that it hasn't been used at all.) Although SMBv1 protocol is obsolete in all ways, it can be re-added to Windows 10 through PowerShell if absolutely necessary.