samba - Oct 2019 - smbclient: Renaming file on DFS root fails with NT_STATUS_OBJECT_PATH_NOT_FOUND

If a file is stored directly on a DFS enabled share, renaming fails with 
NT_STATUS_OBJECT_PATH_NOT_FOUND.
The usecase may sound unusual, but a customer is using NetApp ONTAP 9, 
which by default advertises DFS capabilities for all shares, and he 
cannot disable it for policy reasons.
I can also reproduce the issue with smbd and Windows Server 2012 R2 
(haven't checked with other versions).

IMHO it is caused by:
- Not setting SMB2_HDR_FLAG_DFS when calling smb2cli_req_send() from 
smb2cli_set_info_send()
- cli_resolve_path() returning a full dfs path for the destination, 
which is then passed to cli_rename() to be used in SMB2_FILE_RENAME_INFO

After some patching and testing, I came to this conclusion:

Setting SMB2_HDR_FLAG_DFS solves the issue for smbd, but not for Windows 
Server and not for NetApp.
It seems that the file name in SMB2_FILE_RENAME_INFO must always be a 
non-dfs path and the header flag is ignored:
- A windows client uses a non-dfs path, but sets the header flag
- Linux kernel also uses a non-dfs path and doesn't set the header flag

This means, path handling for cli_rename() needs to be changed.
IMHO there are two possibilities:
- Extend cli_resolve_path() to be able to also return a non-dfs path
- Strip server/share from fname_dst in cli_rename(), e.g. with 
parse_dfs_path() from smbd

On Tue, Oct 22, 2019 at 12:27:17PM +0200, Christoph Ziebuhr via samba
wrote:
> If a file is stored directly on a DFS enabled share, renaming fails with
> NT_STATUS_OBJECT_PATH_NOT_FOUND.
> The usecase may sound unusual, but a customer is using NetApp ONTAP 9,
which
> by default advertises DFS capabilities for all shares, and he cannot
disable
> it for policy reasons.
> I can also reproduce the issue with smbd and Windows Server 2012 R2
(haven't
> checked with other versions).
> 
> IMHO it is caused by:
> - Not setting SMB2_HDR_FLAG_DFS when calling smb2cli_req_send() from
> smb2cli_set_info_send()
> - cli_resolve_path() returning a full dfs path for the destination, which
is
> then passed to cli_rename() to be used in SMB2_FILE_RENAME_INFO
> 
> After some patching and testing, I came to this conclusion:
> 
> Setting SMB2_HDR_FLAG_DFS solves the issue for smbd, but not for Windows
> Server and not for NetApp.
> It seems that the file name in SMB2_FILE_RENAME_INFO must always be a
> non-dfs path and the header flag is ignored:
> - A windows client uses a non-dfs path, but sets the header flag
> - Linux kernel also uses a non-dfs path and doesn't set the header flag
> 
> This means, path handling for cli_rename() needs to be changed.
> IMHO there are two possibilities:
> - Extend cli_resolve_path() to be able to also return a non-dfs path
> - Strip server/share from fname_dst in cli_rename(), e.g. with
> parse_dfs_path() from smbd
Can you send a debug level 10 log from smbclient so I
can see the exact problem ?

Also, can you log a bug at bugzilla.samba.org so we
can track the fix for this ?

Thanks !

Jeremy.

Am 2019-10-22 13:43, schrieb Jeremy Allison:
> Can you send a debug level 10 log from smbclient so I
> can see the exact problem ?
> 
> Also, can you log a bug at bugzilla.samba.org so we
> can track the fix for this ?
Opened https://bugzilla.samba.org/show_bug.cgi?id=14169 and also 
attached screenshots of the relevant tcpdump sections.
Debug log didn't contain any relevant information for this case.