It doesn't happen 100% of the time, but if multiple users open the same Excel document, it may sometimes open as read-only and leave a temp file behind.

It must be stressed that when the document is opened as read-only, no other user has the document open, so it's not a sharing (non-)issue. Instead, one user edits the document, saves and closes, then without rushing things, another user opens the document - and it opens as read-only.

It's been observed with AD users, with macOS El-Capitan, and also with Sierra as the "first opener".

Although we don't have full analysis, we see that the issue is resolved when setting /etc/nsmb.conf on ALL the mac machines as follows:

[default]
file_ids_off=yes

This setting tells the client to stop trusting server-supplied on-disk file ID. The SMB server returns file-id via the QFid create context, or via FILE_INTERNAL_INFORMATION infolevel.

The file id plays a key role in Mac applications because of the HFS+ heritage, where files are identified by CNID. However the HFS CNID is a monotonically-increasing number and Samba provides a file ID made up of the inode number, which can be reused. See https://sambaxp.org/archive_data/SambaXP2016-SLIDES/wed/sambaxp2016-wed-Ralph_Boehme-JuicingTheFruit.pdf slide 30.

What we're looking for with this bug report is for a way to fix the issue without changing things at the client. It's been observed that if the Mac SMB client receives 0 in response for its query, it behaves just as if the "file_ids_off=yes" has been set - both operations clear a bit in the connection details, one at mount time and one afterwards.

See https://github.com/slowfranklin/apple-smb2/blob/master/kernel/smbfs/smbfs_subr_2.c#L68

And also:
https://github.com/slowfranklin/apple-smb2/blob/master/kernel/smbfs/smbfs_vfsops.c#L815

We've also verified experimentally that this fixes the issue in the same way that configuring the client does.

Patch to follow....