Created attachment 17282 [details]
smb.conf from dell server with [homes] and [samba] shares
Linux Distribution: Archlinux
Hardware: Normal x86_64, non-UEFI computers
I have three samba servers, that run in standalone mode sharing [homes] as they have done since Samba 2.0.2a. Upon update from samba 4.15.6-1 -> 4.16.0-1, the `[homes]` shares became immediately undiscoverable by Windows and IOS clients.
The smb.conf is trivial and is attached to this bug report. The `[homes]` definition is the normal:
browseable = No
comment = Home Directories
read only = No
The `[homes]` share ceased being discoverable immediately upon upgrade from 4.15 to 4.16 and a restart of `nmb` and `smb`.
**Behavior On Windows**
When using windows explorer to browse samba shares the user's share normally provided by `[homes]` is no longer visible. However, since windows provides the ability to `map` a network location, you can type the normal `[homes]` address for the user in and the user's share will be found and will then function normally (meaning it is then shown as a browseable share for that user and can be navigated as it normally would). This only requires clicking in the location bar of windows explorer and completing `\\server\username`.
**Behavior on IOS**
For IOS, the `Files` application allows connecting to samba. It has always functioned fine up through 4.15. In `Files` you click `connect to server`, type the hostname for your samba server and all the shares are then listed and available. `[homes]` was fine until 4.16. Beginning with 4.16, just as with Windows, the `[homes]` share is no longer discoverable. However, unlike windows, you do not have the ability to specify a network location for individual shares, so on IOS, the `[homes]` share is unreachable.
I don't have much additional to add. The issue is straight-forward. In 4.15, the `[homes]` share worked as it always had for the standalone servers (at least for the past 20 years). Beginning with 4.16, the user's home share cannot be found by Windows or IOS. In Windows, there is a workaround, by specifying the direct path to the user's home share. On IOS, there is no such workaround and `[homes]` is just broken.
sample smb.conf from one machine attached.
For completeness, the current samba package installed on all three Arch servers is 4.16.1-3 (updated today) -- same behavior.
Identical experience. Samba 4.16.1, clean install with Fedora 36 on a Mac Mini. Home directories that are supposed to be shared with [homes] fail to be offered to a Mac client running MacOS Mojave 10.14.6. The identical smb.conf file worked fine with Samba versions under Fedora 35 with the identical server hardware and no change to the client.
All the other shares are offered and supported normally. It's just the [homes] shares that fail to appear for selection under MacOS.
A workaround was to create a specific share for the user who needs the functionality immediately. This worked. So, it seems unlikely to be a problem with the home folder itself.
Can you upload a debug level 10 log from the version where it's working, and the version where it isn't, so we can examine what we're doing differently that triggers the Mac client bug ?
Or upload wireshark traces from client to server of working and non-working setups, so we can compare ?
Will do Jeremy, I'll have to find the Arch packages on their roll-back server to get the 4.15 packages back and downgrade to grab that trace, will try and get that done by tomorrow for you.
Created attachment 17285 [details]
Level 10 Debug Logs 4.15 [homes] working
This is a level 10 debug after server roll-back to 3/15/22 when arch had samba 4.15. After downgrade and restart -- [homes] worked perfectly. Told IOS (Files app) to connect to server and presto, user share from [homes] and [samba] share both pop up perfectly.
(368 package roll-back needed due to ICU update from 7.0 to 7.1 -- this may be part of the issue).
Created attachment 17286 [details]
Level 10 Debug Logs 4.16 [homes] Not working
Logs from the same server with 4.16 installed with the same attempt to connect from IOS (files app). Upon connection No user share is shown, just the [samba] share.
I wasn't sure what logs were important, so I included all ../samba logs modified during the connect attempts.
Created attachment 17287 [details]
tcpdump on port 445 for 4.15 [homes] working and 4.16 not working
This archive contains tcpdumps from both 4.15 and 4.16 for connection attempts from IOS. The dump was made as:
tcpdump -p -s 0 -w 4.16_tmpdump.bin port 445 and host 192.168.6.197
as shown on https://wiki.samba.org/index.php/Capture_Packets
The 4.15 trace is from the same machine both level 10 logs were produced on. The 4.16 trace is from another server (that was not rolled back to 4.15) Both traces show the attempt to connect from IOS (Files app). 4.15 shows the user's share from [homes], 4.16 fails to find the user's share.
Level 10 logs from both 4.15 successful connect to [homes] share and 4.16 failure to connect to [homes]. Both logs show connect attempt from IOS (Files app). The logs and the 4.15 tcpdump trace is from the same machine as the logs.
tcpdump files for both 4.15 and 4.16. 4.16 trace is from another server that was still running 4.16 and is the same connect attempt from the same IOS device, but connecting to 4.16 doesn't find [homes].
tcpdump was done per https://wiki.samba.org/index.php/Capture_Packets
Let me know if you need anything else.
(p.s. my Samba T-shirt from the 2.0.2 days is well worn out now, time for a new one, amazing to see how the team has grown in 20 years)
This is a problem with the new samba-dcerpcd architecture. The share [vlendec] as the alter ego of [homes] is only added to our internal list of shares whenever the clients authenticate. This kind of authentication does not happen anymore in the rpc srvsvc implementation, so [vlendec] is not added.
We need to patch this as a special case into the netshareenum call.
(In reply to Volker Lendecke from comment #9)
Oh great catch Volker ! I'm happy to review any patches you produce, or if you're too busy let me know where in the code path you want to add the exception and I'll try and fix it.
This bug was referenced in samba master:
Created attachment 17291 [details]
git-am fix for 4.16.next.
Cherry-picked from master.
Hi Jule, this is 4.16 only. Thanks!
Pushed to autobuild-v4-16-test.
This bug was referenced in samba v4-16-test:
Closing out bug report.
This bug was referenced in samba v4-16-stable (Release samba-4.16.2):