Bug 15277 - DFS links don't work anymore on Mac clients since 4.17
Summary: DFS links don't work anymore on Mac clients since 4.17
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.17.3
Hardware: x64 Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Jule Anger
QA Contact: Samba QA Contact
Depends on:
Reported: 2023-01-03 18:40 UTC by Alban Rodriguez
Modified: 2023-01-26 17:52 UTC (History)
1 user (show)

See Also:

Wireshark capture (57.99 KB, application/octet-stream)
2023-01-03 18:40 UTC, Alban Rodriguez
no flags Details
"Raw" patch for 4.17.next (1002 bytes, patch)
2023-01-04 03:13 UTC, Jeremy Allison
no flags Details
git-am fix for 4.17.next. (1.86 KB, patch)
2023-01-04 20:04 UTC, Jeremy Allison
vl: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Alban Rodriguez 2023-01-03 18:40:47 UTC
Created attachment 17716 [details]
Wireshark capture

My original message on the Samba mailing list:


Updating from Samba 4.16.5 to Samba 4.17.3 we just realized DFS links are not resolved anymore when accessing the DFS root shares from a Mac.
As a consequence, the destination shares just appear empty

It still works on a Windows client though.

Our server runs Ubuntu Linux 20.04 LTS, Samba built from source and configured as an AD domain member.
Don’t know if it matters but we are not using the vfs_fruit module (maybe we should …)

Nothing striking in the client log file aside from a «  Cannot get attribute from EA on file » error but not sure it’s related.

Going back to Samba 4.16.5 and it’s working again.

Has anybody else had the same ? I’ve probably missed something in recent changes but I couldn’t find what …


Jeremy Allison <jra@samba.org> replied and invited me to file a bug for this issue.

Today, I could reproduce the behaviour in a simpler test environnement.

Here's my smb.conf config file:

	workgroup = UNIV-LR
	security = ADS
	realm = UNIV-LR.FR

	idmap config * : backend = tdb
	idmap config * : range = 1000000-1999999
	idmap config UNIV-LR : backend  = nss
	idmap config UNIV-LR : range = 1000-999999

	load printers = no
	printing = bsd
	printcap name = /dev/null
	disable spoolss = yes

	allow dns updates = false

	logging = file
	log file = /opt/samba/var/log.%I
	max log size = 0

	path = /shares/DFSRoot
	msdfs root = yes

	path = /shares/Test
	force group = "ACCES PARTAGE TEST"
	create mask = 0
	force create mode = 0660
	directory mask = 0
	force directory mode = 0770
	inherit permissions = yes
	inherit acls = yes
	nt acl support = no
	write list = @"ACCES PARTAGE TEST"
	valid users = @"ACCES PARTAGE TEST"


Comment 1 Jeremy Allison 2023-01-03 18:59:23 UTC
Comment on attachment 17716 [details]
Wireshark capture

MacOSX is sending an SMB2 name of:


with the DFS flag set. According to my tests against latest Windows no SMB2 paths can start with a '\'. You're running into this code:

 Check the path for an SMB2 DFS path.
 SMB2 DFS paths look like hostname\share (followed by a possible \extrapath.
 Path returned from here must look like:
        hostname/share (followed by a possible /extrapath).

static NTSTATUS check_path_syntax_smb2_msdfs(char *path)
        char *share = NULL;
        char *remaining_path = NULL;
        /* No SMB2 names can start with '\\' */
        if (path[0] == '\\') {
                return NT_STATUS_OBJECT_NAME_INVALID;

I'll do some more tests against Windows to see if I'm being too strict here.
Comment 2 Jeremy Allison 2023-01-03 19:11:29 UTC
Yes, looks like I missed a test against Windows and I'm guessing Windows copes with a leading '\\' on an SMB2 DFS path. The following patch should fix it for you:

diff --git a/source3/smbd/smb2_reply.c b/source3/smbd/smb2_reply.c
index 90aa92193b9..70b025f3917 100644
--- a/source3/smbd/smb2_reply.c
+++ b/source3/smbd/smb2_reply.c
@@ -254,9 +254,13 @@ static NTSTATUS check_path_syntax_smb2_msdfs(char *path)
        char *share = NULL;
        char *remaining_path = NULL;
-       /* No SMB2 names can start with '\\' */
        if (path[0] == '\\') {
-               return NT_STATUS_OBJECT_NAME_INVALID;
+               /*
+                * MacOSX sends a '\' at the start of
+                * SMB2 DFS paths.
+                */
+               trim_string(path, "\\", NULL);

I'll add a regression test for this and an "official" patch MR once I'm back at work.
Comment 3 Jeremy Allison 2023-01-04 02:28:01 UTC
Not quite the right fix (doesn't fix it completely). I have a better fix with regression test I'll run through ci.
Comment 4 Jeremy Allison 2023-01-04 03:13:38 UTC
Created attachment 17717 [details]
"Raw" patch for 4.17.next

This is the working fix for 4.17. I'm currently testing a ci-build with a regression test for master, but wanted to make sure you were up and running with 4.17 as soon as possible.
Comment 5 Jeremy Allison 2023-01-04 04:31:16 UTC
MR: https://gitlab.com/samba-team/samba/-/merge_requests/2867

passes ci.
Comment 6 Samba QA Contact 2023-01-04 07:47:04 UTC
This bug was referenced in samba master:

Comment 7 Alban Rodriguez 2023-01-04 15:21:38 UTC
Hello Jeremy,

thank you very much for tracing this issue.
I've applied the patch and it's working fine now!

Have a great day
Comment 8 Jeremy Allison 2023-01-04 20:04:41 UTC
Created attachment 17719 [details]
git-am fix for 4.17.next.

Back-ported from master.

NB. The test for this is not back-ported to 4.17 as there are too many changes in the test infrastructure and supporting client libraries between 4.17 and master.
Comment 9 Jule Anger 2023-01-05 09:08:09 UTC
Pushed to autobuild-v4-17-test.
Comment 10 Samba QA Contact 2023-01-05 10:02:03 UTC
This bug was referenced in samba v4-17-test:

Comment 11 Jule Anger 2023-01-05 17:17:10 UTC
Closing out bug report.

Comment 12 Samba QA Contact 2023-01-26 17:52:22 UTC
This bug was referenced in samba v4-17-stable (Release samba-4.17.5):