Re: Potential smb/dfs regression introduced in kernel 6.6

[Paulo Alcantara <pc@manguebit.com>]

[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]

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.

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.

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

What does NetApp say about failing those FSCTL_GET_REPARSE_POINT IOCTL
requests?

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


[-- Attachment #2: w2k22.pcapng --]
[-- Type: application/octet-stream, Size: 15648 bytes --]