Duplicate SMB file_ids leading to Windows client cache poisoning
tom at talpey.com
Fri Dec 10 15:48:40 UTC 2021
Thanks for these, I'll catch up on reading, shortly.
MS-FSCC section 2.1.9 defines the identifier that MS-SMB2 calls
the DiskFileId. Clients typically use it to perform caching,
which is to say, it's going to be an upper layer issue - the SMB
protocols don't actually process it, they just pass it along.
Ralph, if you set it to 0 or ffff, it may "work" but the file
might not be cached. That seems undesirable. Is this issue
purely on Macs? What actually fails, and what works?
On 12/10/2021 8:18 AM, Ralph Boehme wrote:
> On 12/10/21 12:49, Andrew Walker wrote:
> exactly. Thanks for digging out the references. Didn't remember I ever
> wrote such a comprehensive summary. :)
> So what shall we do? Back to inode numbers? I've been recommending
> fruit:zero_file_id=yes to customers who've been reporting strange issues
> with Mac clients. That causes Samba to return 0 file-ids which has been
> problematic in the past, but it seems to be working atm.
> Tom, do you know if it using any of the mentioned fallbacks from MS-FSCC:
> For file systems that do not support a 64-bit file ID,
> this field MUST be set to 0, and MUST be ignored.
> For files for which a unique 64-bit file ID cannot be
> established, this field MUST be set to 0xffffffffffffffff,
> and MUST be ignored.
> would be a way forward? Macs can deal with 0, not sure about UINT64_MAX.
More information about the samba-technical