Re: Potential smb/dfs regression introduced in kernel 6.6

[Tom Talpey <tom@talpey.com>]

Thanks for cc'ing me, I don't think I saw the original message.

On 7/17/2024 2:24 PM, Paulo Alcantara wrote:
> Hi Sebastian,
> 
> Sorry for the delay as I've been quite busy with other stuff lately.
> [Cc Steve, Tom]
> 
> Steinbeißer, Sebastian	<Sebastian.Steinbeisser@lrz.de> writes:
> 
>> we have set up a share without signing & encryption and I reran the
>> commands.
>>
>> Find the output attached.
> 
> Thanks!
> 
> By looking at the trace_fail.pcap file, the problem seems related to
> NetApp server not allowing the client to query the reparse point data
> buffer from volume0{2,3} files by failing the SMB2_IOCTL
> FSCTL_GET_REPARSE_POINT requests with STATUS_INVALID_DEVICE_REQUEST:
> 
> ...
> SMB2 546 Create Request File: volume02;GetInfo Request FILE_INFO/SMB2_FILE_ALL_INFO;Ioctl Request FSCTL_GET_REPARSE_POINT;Close Request
> SMB2 678 Create Response File: volume02;GetInfo Response;Ioctl Response,Error: STATUS_INVALID_DEVICE_REQUEST;Close Response
> ...
> SMB2 546 Create Request File: volume03;GetInfo Request FILE_INFO/SMB2_FILE_ALL_INFO;Ioctl Request FSCTL_GET_REPARSE_POINT;Close Request
> SMB2 678 Create Response File: volume03;GetInfo Response;Ioctl Response, Error: STATUS_INVALID_DEVICE_REQUEST;Close Response
> 
> The client knows that volume0{2,3} files both contain reparse points by
> parsing the SMB2_CREATE responses in packets #545 and #551 (as specified
> in MS-SMB2 2.2.14), so in order to figure out what kind of reparse
> points they have, the client then sends SMB2_IOCTL
> FSCTL_GET_REPARSE_POINT requests which the server fails with
> STATUS_INVALID_DEVICE_REQUEST.

I don't have the original trace, so I can't see packets #545 and #551.

On the face of it, failing the FSCTL_GET_REPARSE_POINT with this error
would be quite unexpected. MS-FSA says:

-- Support for this operation is optional. If the object store does not
-- implement this functionality, the operation MUST be failed with
-- STATUS_INVALID_DEVICE_REQUEST

So it appears the server reported the file as a reparse point, but does
not support FSCTL_GET_REPARSE_POINT. On the other hand, it did not
return STATUS_REPARSE to the SMB2_CREATE? Seems like an incomplete
implementation.

> The old behavior was simply accessing those volumes as regular
> directories which became problematic due to users reporting duplicated
> inode numbers when accessing them from within SMB shares, which could
> potentially lead to data corruptions.  Newer kernels set those files as
> automounts with 'noserverino' set to avoid inode number collisions.

I guess the older clients saw the directory bit, ignored the reparse,
and just sent the next op as if it were simply a directory. The server
in turn fixed up the reparse and followed it, operating on the target
directory. Duplicate inode numbers seems like the tip of that iceberg.
The new behavior is much more correct from an SMB2 protocol standpoint.
Clients are supposed to know they've been reparsed/redirected.

> Please find attached a similar network trace when accessing a directory
> with same reparse point (IO_REPARSE_TAG_MOUNT_POINT) against Windows
> Server 2022.

Yes, this confirms the behavior (packet #43), and indicates the Windows
client is doing the same thing, and probably never succeeded. It would
surprise me a lot if NetApp never heard this.

> What does NetApp say about failing those FSCTL_GET_REPARSE_POINT IOCTL
> requests?

I'd love to hear their response too. It's technically optional, but
doesn't make much sense.

Tom.

> Do you think that any of these server-side options [1] would help?
> 
>          [-is-use-junctions-as-reparse-points-enabled {true|false}]
>          [-widelink-as-reparse-point-versions <CIFS Dialects>,…​]
> 
> Tom & Steve, any thoughts on this?  Are we missing something in the
> client to handle such case?
> 
> [1] https://docs.netapp.com/us-en/ontap-cli-98/vserver-cifs-options-modify.html
>