Duplicate SMB file_ids leading to Windows client cache poisoning

Tom Talpey 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:
>> Correct?
> 
> 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.
> 
> Thanks!
> -slow
> 



More information about the samba-technical mailing list