Mojave SMB shares have no content

[sshort]

My org is running into an issue with SMB shares in Mojave where they successfully mount, but no files or content appear (folder size shows 0 bytes). All of the threads I found in searches revolved around SMB refusing to mount at all, but that's not the issue here.

-We're using Centrify, but the problem occurs even on a non-Centrify AD-bound Mac
-Seemed to creep up around 10.14.2, and issue continues in 10.14.4
-Macs on High Sierra or Sierra aren't affected.
-Content appears as expected directly on the server, or when mounted in Windows 10

-Using cifs:// instead of smb:// seemed to be a workaround, but after a while the behavior returns
-Not all users are equally affected. Some are able to view content in a limited number of additional SMB shares (but then over time that fails), others cannot see regardless of what's mounted.
-Occurs when using Connect to Server... in the GUI, or using mount_smbfs on the command line.

Any ideas? I'm hoping someone can point us in the right direction...

[jhuls]

Any chance that those managing the server(s) are using access based enumeration? I won't say that this is your problem but I will say that I've seen weird stuff when using it which has seemed to have been from admins thinking like Windows users and not Mac users. The idea behind it is to hide files and folders that a user has no business seeing. It more or less gives a Windows admin the ability to do what Novell use to do by default. That's the good thing about it. The bad thing about it is that in some cases you can then only get to your data by directly mounting the specific area that you do have rights to which includes the server, share, and folder path. In those cases you cannot just mount the share or server and then click through to get to your stuff and it will look like nothing is there.

[sshort]

I worked with our network team and access based enumeration is disabled. Thanks for the tip @jhuls. At least I can rule that out, I'd never heard of that feature before.

[dustink]

If you look at the raw DFS link objects in ADSI, the broken ones have Interlink=on set in the msDFS-PropertiesV2 attribute. There are also some differences with GUIDs/TTL.
Distributed File System (DFS) interlink: A special form of DFS link whose link target is a DFS domain-based namespace.
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dfsnm/a9bc4403-a862-48b9-b99b-1b44a887d177#gt_ebaa4758-1010-49c9-b924-7fec6e4f2306

[sshort]

For anyone interested, our team discovered the root issue. When select DFS shares were initially configured, the symlinks did not include the FQDN for our org. So something like smb://path/to/user/share would show no content, but smb://$FQDN/path/to/user/share works as expected. We're going through the process of identifying which shares are affected, but it explains why not everyone on Mojave experienced the issue.