%i token does not expand on 4.13.14+dfsg-0ubuntu0.20.04.2

In case it helps to reproduce the problem, or if its useful to anyone else affected by this, we downgraded (and have also pinned) the following packages:

apt-get install samba=2:4.13.14+dfsg-0ubuntu0.20.04.1 samba-common=2:4.13.14+dfsg-0ubuntu0.20.04.1 samba-common-bin=2:4.13.14+dfsg-0ubuntu0.20.04.1 libwbclient0=2:4.13.14+dfsg-0ubuntu0.20.04.1 samba-libs=2:4.13.14+dfsg-0ubuntu0.20.04.1 python3-samba=2:4.13.14+dfsg-0ubuntu0.20.04.1 libsmbclient=2:4.13.14+dfsg-0ubuntu0.20.04.1 samba-dsdb-modules=2:4.13.14+dfsg-0ubuntu0.20.04.1 samba-vfs-modules=2:4.13.14+dfsg-0ubuntu0.20.04.1 winbind=2:4.13.14+dfsg-0ubuntu0.20.04.1

Hi Adam,

Thank you for taking the time to file a bug report.

Would you mind providing a reproducer for the bug you are experiencing? In special, what client tools are you using which are not being able to properly expand the token?

While I do get the error message regarding a missing file at "/data/config/0.0.0.0/shares" when starting smbd. That should be expected since the %i token is supposed to be expanded for clients.

I could not reproduce the issue using client applications though.

For instance, running "findsmb" from smbclient 2:4.13.14+dfsg-0ubuntu0.20.04.1 will generate a /var/log/samba/log.$SERVER_IP file which does include an entry for the proper file named over the server IP address.

It would also be nice if you could increase the debug level when running samba and attach your logs here.

Since there is not enough information in your report to begin triage or to
differentiate between a local configuration problem and a bug in Ubuntu, I
am marking this bug as "Incomplete". We would be grateful if you would:
provide a more complete description of the problem, explain why you
believe this is a bug in Ubuntu rather than a problem specific to your
system, and then change the bug status back to "New".

For local configuration issues, you can find assistance here:
http://www.ubuntu.com/support/community

I've seen this problem on all the clients I've tried. Some examples include Windows 10 (when running "net use \\SERVER\SHARE") and Bionic clients (with smbclient 4.7.6+dfsg~ubuntu-0ubuntu2.24 when running e.g. smbclient -L //SERVER)

I also see this with smbclient as distributed to the Focal test server I've been using to investigate this problem (currently running smbclient 4.13.14+dfsg-0ubuntu0.20.04.2). I'll stick with that Focal client for debugging purposes. When I use "include=/data/config/%i/shares" in the server config, I see:

# smbclient -L //localhost -U guest
Enter WORKGROUP\guest's password:

        Sharename Type Comment
        --------- ---- -------
        IPC$ IPC IPC Service (smbtest server (Samba, Ubuntu))

i.e. I don't see the share I've configured. If I instead "include=/data/config/$IP/share" where $IP is the literal IP address of the server, then:

# smbclient -L //localhost -U guest
Enter WORKGROUP\guest's password:

        Sharename Type Comment
        --------- ---- -------
        alt36 Disk
        IPC$ IPC IPC Service (smbtest server (Samba, Ubuntu))

i.e. the share I've defined in the included file becomes visible.

I've now set log level=10 on the server's smb.conf. The attached zip contains log.smbd.good and log.smbd.bad which are the server logs that arise from running smbclient -L as described above (and correspond, respectively, to using a static string for 'include' versus using %i). Note that log.smbd.bad reports "Can't find include file /data/config/0.0.0.0/shares"

Hi Athos,

Re-reading your comment #2, you mention seeing generated logfiles at /var/log/samba/log.$SERVER_IP . I think that means you're using a different smb.conf to the one I posted, which had

log file = /var/log/samba/log.%m

and so wouldn't generate log files including the server IP in the name.

Is it possible there are other differences in your smb.conf compared to the one in my description? If you could post the smb.conf you're using I'd be happy to try that on my test instance to check what behaviour I see.

Hi Adam,

the changes between 4.13.14+dfsg-0ubuntu0.20.04.1 and .2 do not really touch anything related to the IP address expansion; the change is only about (not) auto-populating the sambashare unix group at install time. This is the diff of the packages:

https://launchpadlibrarian.net/570713970/samba_2%3A4.13.14+dfsg-0ubuntu0.20.04.1_2%3A4.13.14+dfsg-0ubuntu0.20.04.2.diff.gz

Let us know if you think this may be in any way related to the problem you're hitting, but I doubt it. It seem to me that you already double checked this, but could you please confirm one last time that:

- 4.13.14+dfsg-0ubuntu0.20.04.1 corrently expands %i
- 4.13.14+dfsg-0ubuntu0.20.04.2 does NOT correctly expand %i

on the same system, same config file, and in general same conditions? If this is the case my suspect will go towards the newer build dependencies .2 has been built against. In this case we need to prepare a new .1 build done against the newer build deps, and see how it behaves. I know you already rebuilt samba from source, but here I think we need to replicate the same build procedure that's used to build the .debs (the devil is in the details, and there are so many of them).

Hi Paride,

Yeah, I checked the changelog for 4.13.14+dfsg-0ubuntu0.20.04.2 and the minor change reported there did not sound like it would have any relation to the behavior I've described. But none the less, I am confident I see a difference between the .1 and .2 set of packages.

I've created a few Docker containers that demonstrate this on a 'clean' system based on the ubuntu:20.04 image. See:

https://gitlab.developers.cam.ac.uk/alt36/lp1952633

The Dockerfile in all three directories is identical, except when they explicitly install either the .1 or the .2 packages. The only other difference between the three directories is in smb.conf: the .1 and .2-dynamic versions have "include = /data/config/%i/shares", whilst the .2-static version has "include = /data/config/127.0.0.1/shares".

In each case, the share definition which should be included has a root preexec script which is called with %i as an argument, and that script just echoes the arguments to a log file. The containers each run demo.sh which will:

1. start smbd
2. run a "smbclient ls" command
3. cat the logfile contents.

The gitlab repo has an associated docker container registry with images I've pushed for each of the three Dockerfiles, so you should be able to repeat the following...

Using the .1 packages. The "smbclient ls" succeeds, and the logfile contains 127.0.0.1 as expected:

$ docker run --rm registry.gitlab.developers.cam.ac.uk/alt36/lp1952633:20.04.1
 * Starting SMB/CIFS daemon smbd
   ...done.
  . D 0 Thu Dec 2 18:32:07 2021
  .. D 0 Thu Dec 2 18:32:08 2021
  examplefile N 0 Thu Dec 2 18:32:07 2021

                61794184 blocks of size 1024. 15564168 blocks available
Output of "prexec.sh %i:"
127.0.0.1
 * Stopping SMB/CIFS daemon smbd
   ...done.

Using the .2 packages and an 'include' which does not use %i. The share definition is included and the "smbclient ls" succeeds, but the logfile now contains 0.0.0.0

$ docker run --rm registry.gitlab.developers.cam.ac.uk/alt36/lp1952633:20.04.2-static
 * Starting SMB/CIFS daemon smbd
   ...done.
  . D 0 Thu Dec 2 18:36:53 2021
  .. D 0 Thu Dec 2 18:36:54 2021
  examplefile N 0 Thu Dec 2 18:36:53 2021

                61794184 blocks of size 1024. 15564152 blocks available
Output of "prexec.sh %i:"
0.0.0.0
 * Stopping SMB/CIFS daemon smbd
   ...done.

Finally, using the .2 packages and an 'include' using %i. smbclient does not connect, and thus the logfile doesn't exist because we don't get as far as running the root preexec script specified in the share definition

$ docker run --rm registry.gitlab.developers.cam.ac.uk/alt36/lp1952633:20.04.2-dynamic
 * Starting SMB/CIFS daemon smbd
   ...done.
tree connect failed: NT_STATUS_BAD_NETWORK_NAME
Output of "prexec.sh %i:"
cat: /tmp/preexec.log: No such file or directory
 * Stopping SMB/CIFS daemon smbd
   ...done.

I see that 2:4.13.14+dfsg-0ubuntu0.20.04.3 was released today. I've built and uploaded a container using that version, and the %i token expansion now seems to work again:

====

$ docker run --rm registry.gitlab.developers.cam.ac.uk/alt36/lp1952633:20.04.3-dynamic
 * Starting SMB/CIFS daemon smbd
   ...done.
  . D 0 Mon Dec 6 16:08:08 2021
  .. D 0 Mon Dec 6 16:08:10 2021
  examplefile N 0 Mon Dec 6 16:08:08 2021

                61794184 blocks of size 1024. 14908796 blocks available
Output of "prexec.sh %i:"
127.0.0.1

====

However, the changelog for .3 references the upstream samba bugs 14901 (changes around 'map username script') and 14918 (failure to delete a directory containing dangling symlinks), neither of which seem to be related to my bug report here. My guess is thus that something unintended happened with the binaries shipped with .2

Because this broke all of our production fileservers I'm keen to get to the bottom of what happened and to make sure there isn't a repeat with future releases.

In #5 Paride raised a possible suspicion with "the newer build dependencies .2 has been built against." I'm not sure where to find those, or to see if they've been changed again for the .3 build. If there's anything more I can do here I'm happy to repeatedly try building with different options and test the results.

Hi Adam,

Good to hear the issue was fixed for you. Tracking down the build dependencies changes between those two versions might not be easy, you could go through the publication history of each of them in Launchpad and check but I do not think this worth. I am setting the status of this bug to Fix Released.

I agree with Lucas: chasing the exact reason of the behavior you observed is a very time consuming task. This requires checking the build logs of .1 and .2:

https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/22389258

https://launchpad.net/ubuntu/+source/samba/2:4.13.14+dfsg-0ubuntu0.20.04.2/+build/22419082

and trying to reproduce the exact build environment of the buggy build, hoping to spot what exactly caused the issue. This is not easy as the entire packageset is slowly moving, due to SRUs.

I did a diff between the "Build environment" sections of the buildlogs, but couldn't find an obvious candidate to check. I fully understand your desire to find out what happened exactly, but given that the problem seems to be gone and that this was the only bug report about it, I doubt we'll be able to allocate more time for it.