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
Created attachment 15564 [details] Tree Connect Response DFS capability is advertised. NetApp doesn't set DFS share flags (which is also not required and out of scope for this report).
Created attachment 15565 [details] SetInfo Request with SMB2_FILE_RENAME_INFO DFS flag is not set. Filename in SMB2_FILE_RENAME_INFO is a full dfs path.
Created attachment 15566 [details] SetInfo Response Rename failed with STATUS_OBJECT_PATH_NOT_FOUND
Can you please also upload a trace showing the traffic between a Windows client and a Windows server, so we peek how exactly Windows does it? Thanks.
Created attachment 15567 [details] pcap of failed rename to NetApp
Created attachment 15568 [details] pcap of successful rename from windows 10 client to windows server
Created attachment 15569 [details] git-am prototype fix for master.
Works for me. Haven't checked with smb1 though. The commit message for smb1/smb2 seems to be interchanged. By the way: Found a function cli_ntrename() which is not called anywhere. Is it still required or just there for compability with older applications?
Thanks - this is a prototype patch so I'll fix that up and add a test (at least SMB2-only:-) before proposing this for an actual fix. Thanks for confirming it fixes the issue against NetApp (I tested it locally against Samba but don't have access to a NetApp).
Yes, cli_ntrename() isn't used anywhere - it just maps onto cli_ntrename_internal() which is used by the hardlink code. I'll still add a fix for it into the patchset, it's easy enough to do. Thanks for testing !
I now have another issue: if the destination already exists I get STATUS_OBJECT_PATH_SYNTAX_BAD (in version 4.5.16, haven't checked with master yet)
Created attachment 15570 [details] updated git-am fix for master.
In 4.5.x cli_smb2_rename() doesn't use the 'replace' paramter - it's missing from the cli_rename() call. In master it does, you add the '-f' parameter to force overwrite (cli_rename() takes an extra 'replace' parameter, set if you add -f to the command line in smbclient).
Ignore comment #11. My local build- and test-environment was broken.
*** Bug 13599 has been marked as a duplicate of this bug. ***
(In reply to Jeremy Allison from comment #12) that patch for master never went into master and also doesn't cleanly apply any more. Was this patch still WIP, Jeremy?
Jeremy: ping
I have updated the patch for version 4.15.1 of the samba library. I am going to attach here. Thank you.
Created attachment 17067 [details] DFS rename patch
I'm working on this now - Paulo, thanks for your patch but it isn't complete. Please give me some time to get an updated patch working. Thanks. Jeremy.
Ah. This is interesting. Samba also won't allow an SMB2 rename call on a MSDFS share from smbclient. This is because we only set the SMB2_HDR_FLAG_DFS flag in the incoming packet on the SMB2_CREATE call, and SMB2 rename does the following operations: SMB2_CREATE(src_path) // We set SMB2_HDR_FLAG_DFS here for a MSDFS share. SMB2_SETINFO: SMB2_FILE_RENAME_INFO(dst_path). // We don't set SMB2_HDR_FLAG_DFS Currently from smbclient, dst_path is a MSDFS path but we don't set the flag, so even though the rename code inside smbd will cope with a MSDFS path (as used in the SMB1 SMBmv call) it fails as the correct flag isn't set. We shouldn't be sending MSDFS paths for a SETINFO rename / hardlink target. I'll add a regression test and fix.
Created attachment 17148 [details] git-am fix for master. Here's what I'm planning to put into gitlab-ci.
In CI at: https://gitlab.com/samba-team/devel/samba/-/pipelines/463196570
This bug was referenced in samba master: d7deb876053ef45313026b4dea9ee1b376153611 44cc9fb0e01b3635804f41e03f9b20afc3bfe36c 2abba0ea109d7a3a0b0cb4a7030293f70c2d9d8a 4bdbe3c2fc0c35635474ae526896b28f55142aca cf3e5724422d8becd045542be196dfea6ac9ec2b dd0317f6ecb572a80893405daa83e079dbcdf113 4473aea926fe4ddd23a6e0913009bb1a0a1eaa90 b9b82f3611c56e837e9189f5275ae9a78e647262
Created attachment 17149 [details] git-am fix for 4.16.RCnext, 4.15.next, 4.14.next. Cherry-pick from master. Applies cleanly to 4.16.rcNext, 4.15.next, 4.14.next.
Comment on attachment 17149 [details] git-am fix for 4.16.RCnext, 4.15.next, 4.14.next. lgtm
reassigning to Jule for inclusion in 4.16. 4.15, 4.14
Pushed to autobuild-v4-{16,15,14}-test.
This bug was referenced in samba v4-15-test: 235ecfbbe665ecfdefd0a154104791ef611ac4ad 88eee5c47434c2bd2e0148d017e6456ef751a882 ce29aecbd96b28f502dcbda760dd38ced11ff7b1 e7d0b7aa06410c50c5834e217ec6b6b34eedd50f fd593ab3a0cdb94e6c2d3eccbf1797a760c2112f be0b115b8aed783361274b78cac78f9817fcdf60 1d85a72d77ec682ce143ce3954ef54085bba9dfe 36189b0be18ff849937648f26a48b5fc01e9327f
This bug was referenced in samba v4-14-test: 6ef8465cf018fd9c4d85da232400b31b26be2dd1 231507270b465898a164c78160a5baf58727d5c6 5790a73a0b68fd558de4b45a3eada85c7b2e78f5 fdd645fa7028626178f3710f431f52322347c705 9de91537f3dc19b8154ecdd0bec4762c4de7422c f9a36e1aebf3c80682def093e91a66406827c86a 5b653b0b076a6632c9fb3c3c59dab95462a5b304 885fafdee3b2cd8daf35b7f7d08c39f8a1100ccc
This bug was referenced in samba v4-16-test: 95aca464c7c500f798640a7979dade699931cefc 738fbcca5440f3a8ccbeb6e74b2a6560a6b74533 62ce0c8f55b52f487b33b49cb4438eff69c138ac 96122869594760360b2ae26d194c7908bd900bd4 01b06586f195a7eb592f18e5f5657ca9f2fa031d 1304041a4fd2fbd5c35b5f5235345b40b5f17bf0 35a250f49ee8ae49fc8a9dfbb704211b189c9435 cdcf23aac2f979d1ffa33a3a7b3fe98aa47c83d7
Closing out bug report. Thanks!
This bug was referenced in samba v4-16-stable (Release samba-4.16.0rc3): 95aca464c7c500f798640a7979dade699931cefc 738fbcca5440f3a8ccbeb6e74b2a6560a6b74533 62ce0c8f55b52f487b33b49cb4438eff69c138ac 96122869594760360b2ae26d194c7908bd900bd4 01b06586f195a7eb592f18e5f5657ca9f2fa031d 1304041a4fd2fbd5c35b5f5235345b40b5f17bf0 35a250f49ee8ae49fc8a9dfbb704211b189c9435 cdcf23aac2f979d1ffa33a3a7b3fe98aa47c83d7
This bug was referenced in samba v4-15-stable (Release samba-4.15.6): 235ecfbbe665ecfdefd0a154104791ef611ac4ad 88eee5c47434c2bd2e0148d017e6456ef751a882 ce29aecbd96b28f502dcbda760dd38ced11ff7b1 e7d0b7aa06410c50c5834e217ec6b6b34eedd50f fd593ab3a0cdb94e6c2d3eccbf1797a760c2112f be0b115b8aed783361274b78cac78f9817fcdf60 1d85a72d77ec682ce143ce3954ef54085bba9dfe 36189b0be18ff849937648f26a48b5fc01e9327f
This bug was referenced in samba v4-14-stable (Release samba-4.14.13): 6ef8465cf018fd9c4d85da232400b31b26be2dd1 231507270b465898a164c78160a5baf58727d5c6 5790a73a0b68fd558de4b45a3eada85c7b2e78f5 fdd645fa7028626178f3710f431f52322347c705 9de91537f3dc19b8154ecdd0bec4762c4de7422c f9a36e1aebf3c80682def093e91a66406827c86a 5b653b0b076a6632c9fb3c3c59dab95462a5b304 885fafdee3b2cd8daf35b7f7d08c39f8a1100ccc