Created attachment 17966 [details] log If host msdfs = yes msdfs root = yes is enabled renaming files via explorer is broken with 4.18. See attached log and network capture.
Created attachment 17967 [details] network capture
What version of Windows ? The DFS names are not starting with '\' from this client.
Just checked the server code, we cope with that. Still looking..
(In reply to Jeremy Allison from comment #2) the client is an up-to-date Windows 10 machine
Is it the case that DFS path normilation should only be called for SMB2-CREATE requests, but not for others? In the case here, the request is SMB2-SETINFO with RENAME info level. The path is a local relative path, not a DFS path, but the SMB2 packet has the DFS flag set. So when we process the path in our rename code, we trigger DFS path processing which ends up with a local path of ".".
(In reply to Ralph Böhme from comment #5) I think that's the case. But I thought I had tests for that.
Yes, I do test this. Check out: source3/torture/test_smb2.c /* * Now show that renames use relative, * not full DFS paths. */ /* Full DFS path should fail. */ status = smb2_dfs_rename(cli, fid_persistent, fid_volatile, "ANY\\NAME\\renamed_file"); if (!NT_STATUS_EQUAL(status, NT_STATUS_OBJECT_PATH_NOT_FOUND)) { printf("%s:%d Rename of %s -> %s should fail " "with NT_STATUS_OBJECT_PATH_NOT_FOUND. Got %s\n", __FILE__, __LINE__, "BAD\\BAD\\file", "ANY\\NAME\\renamed_file", nt_errstr(status)); goto err; } /* Relative DFS path should succeed. */ status = smb2_dfs_rename(cli, fid_persistent, fid_volatile, "renamed_file"); if (!NT_STATUS_IS_OK(status)) { printf("%s:%d: Rename of %s -> %s should succeed. " "Got %s\n", __FILE__, __LINE__, "BAD\\BAD\\file", "renamed_file", nt_errstr(status)); goto err; }
The tests must not be comprehensive enough. I don't have time to look at this today, maybe next week. If you want to take over I won't object.
Fixed by 2c40e28908e9fab8dce7e50d3357b513d9af78c4 in 4.19.