Bug 15062 - Update from 4.15 to 4.16 breaks discovery of [homes] on standalone server from Win and IOS
Summary: Update from 4.15 to 4.16 breaks discovery of [homes] on standalone server fr...
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.16.1
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Jule Anger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-10 04:21 UTC by David C. Rankin
Modified: 2022-06-13 06:55 UTC (History)
2 users (show)

See Also:


Attachments
smb.conf from dell server with [homes] and [samba] shares (788 bytes, text/plain)
2022-05-10 04:21 UTC, David C. Rankin
no flags Details
Level 10 Debug Logs 4.15 [homes] working (83.98 KB, application/x-xz)
2022-05-13 07:16 UTC, David C. Rankin
no flags Details
Level 10 Debug Logs 4.16 [homes] Not working (85.53 KB, application/x-xz)
2022-05-13 07:18 UTC, David C. Rankin
no flags Details
tcpdump on port 445 for 4.15 [homes] working and 4.16 not working (26.93 KB, application/x-xz)
2022-05-13 07:39 UTC, David C. Rankin
no flags Details
git-am fix for 4.16.next. (13.73 KB, patch)
2022-05-18 20:38 UTC, Jeremy Allison
vl: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David C. Rankin 2022-05-10 04:21:52 UTC
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:

    [homes]
            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.
Comment 1 David C. Rankin 2022-05-10 08:02:18 UTC
For completeness, the current samba package installed on all three Arch servers is 4.16.1-3 (updated today) -- same behavior.
Comment 2 Bill Burgess 2022-05-13 00:31:21 UTC
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.
Comment 3 Jeremy Allison 2022-05-13 02:05:22 UTC
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 ?

Thanks !
Comment 4 David C. Rankin 2022-05-13 04:46:03 UTC
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.
Comment 5 David C. Rankin 2022-05-13 07:16:44 UTC
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).
Comment 6 David C. Rankin 2022-05-13 07:18:55 UTC
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.
Comment 7 David C. Rankin 2022-05-13 07:39:52 UTC
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.
Comment 8 David C. Rankin 2022-05-13 07:50:14 UTC
Okay Jeremy, 

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)
Comment 9 Volker Lendecke 2022-05-13 09:01:22 UTC
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.
Comment 10 Jeremy Allison 2022-05-13 16:57:03 UTC
(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.
Comment 12 Samba QA Contact 2022-05-18 17:43:04 UTC
This bug was referenced in samba master:

3145131809269a33ad07261f94ee6e09e1850365
20cbade5b164c0e9eec744bd5a564110923a0c61
04e0e02c6951e327130210e44deb87b9a303cdb3
Comment 13 Jeremy Allison 2022-05-18 20:38:02 UTC
Created attachment 17291 [details]
git-am fix for 4.16.next.

Cherry-picked from master.
Comment 14 Volker Lendecke 2022-05-19 07:06:14 UTC
Hi Jule, this is 4.16 only. Thanks!
Comment 15 Jule Anger 2022-05-20 08:16:52 UTC
Pushed to autobuild-v4-16-test.
Comment 16 Samba QA Contact 2022-05-20 09:11:03 UTC
This bug was referenced in samba v4-16-test:

807ce67629deb17b97d55eadde09fb5881023bcd
344ff937f203a9545ab8a56710499bf2c25691ee
f23f9132f7c0205220e11732ee5b0c69ea8467dd
Comment 17 Jule Anger 2022-05-20 10:44:02 UTC
Closing out bug report.

Thanks!
Comment 18 Samba QA Contact 2022-06-13 06:55:54 UTC
This bug was referenced in samba v4-16-stable (Release samba-4.16.2):

807ce67629deb17b97d55eadde09fb5881023bcd
344ff937f203a9545ab8a56710499bf2c25691ee
f23f9132f7c0205220e11732ee5b0c69ea8467dd