** Description changed:
[ Impact ]
- * An explanation of the effects of the bug on users and justification
- for backporting the fix to the stable release.
+ After upgrading Samba from 2:4.15.13+dfsg-0ubuntu1.5 to
+ 2:4.15.13+dfsg-0ubuntu1.8 (to fix LP: #2120811), the %m variable in the
+ smb.conf configuration file stopped resolving to the hostname as it
+ previously did, and now resolves to an IP address.
- * In addition, it is helpful, but not required, to include an
- explanation of how the upload fixes this bug.
+ Note this is the second regression in the original LP: #2116098 SRU,
+ which changed samba to cope with security changes that landed in Windows
+ Server.
[ Test Plan ]
- * detailed instructions how to reproduce the bug
+ * detailed instructions how to reproduce the bug
- * these should allow someone who is not familiar with the affected
- package to reproduce the bug and verify that the updated package
- fixes the problem.
+ * these should allow someone who is not familiar with the affected
+ package to reproduce the bug and verify that the updated package
+ fixes the problem.
- * if other testing is appropriate to perform before landing this
- update, this should also be described here.
+ * if other testing is appropriate to perform before landing this
+ update, this should also be described here.
[ Where problems could occur ]
- * Think about what the upload changes in the software. Imagine the
- change is wrong or breaks something else: how would this show up?
+ * Think about what the upload changes in the software. Imagine the
+ change is wrong or breaks something else: how would this show up?
- * It is assumed that any SRU candidate patch is well-tested before
- upload and has a low overall risk of regression, but it's important
- to make the effort to think about what ''could'' happen in the event
- of a regression.
+ * It is assumed that any SRU candidate patch is well-tested before
+ upload and has a low overall risk of regression, but it's important
+ to make the effort to think about what ''could'' happen in the event
+ of a regression.
- * This must never be "None" or "Low", or entirely an argument as to why
- your upload is low risk.
+ * This must never be "None" or "Low", or entirely an argument as to why
+ your upload is low risk.
- * This both shows the SRU team that the risks have been considered,
- and provides guidance to testers in regression-testing the SRU.
+ * This both shows the SRU team that the risks have been considered,
+ and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
- * Anything else you think is useful to include
+ * Anything else you think is useful to include
- * Make sure to explain any deviation from the norm, to save the SRU
- reviewer from having to infer your reasoning, possibly incorrectly.
- This should also help reduce review iterations, particularly when the
- reason for the deviation is not obvious.
+ * Make sure to explain any deviation from the norm, to save the SRU
+ reviewer from having to infer your reasoning, possibly incorrectly.
+ This should also help reduce review iterations, particularly when the
+ reason for the deviation is not obvious.
- * Anticipate questions from users, SRU, +1 maintenance, security teams
- and the Technical Board and address these questions in advance
-
+ * Anticipate questions from users, SRU, +1 maintenance, security teams
+ and the Technical Board and address these questions in advance
[ Original Description ]
Description:
After upgrading Samba from 2:4.15.13+dfsg-0ubuntu1.5 to
2:4.15.13+dfsg-0ubuntu1.8, the %m variable in the smb.conf configuration
file stopped resolving to the hostname as it previously did. This issue
affects configurations that rely on %m for host-based home directory
mapping.
Use Case:
My Samba server is configured to serve user home directories based on
both hostname and username. Here is the relevant section of my
/etc/samba/smb.conf:
[homes]
comment = Home Directories
path = /share/samba/%m/%S
This configuration had worked for years. For example, when client1
connected as user1, the server would serve the home directory from:
/share/samba/client1/user1
Observed Behavior:
Up to version 2:4.15.13+dfsg-0ubuntu1.6:
%m was correctly substituted with the client's hostname (e.g., client1).
In version 2:4.15.13+dfsg-0ubuntu1.7:
%m was empty (""), causing Samba to try accessing /share/samba//user1,
which failed due to a nonexistent path.
In version 2:4.15.13+dfsg-0ubuntu1.8:
%m is now set to the client's IP address (e.g., 192.168.1.123) instead of
the hostname, resulting in paths like:
/share/samba/192.168.1.123/user1
This is not the intended behavior and breaks existing configurations.
Debugging:
To debug the value of %m, I added the following line to the config:
preexec = /bin/sh -c 'echo m=%m >> /tmp/smb.log'
Results:
With 2:4.15.13+dfsg-0ubuntu1.5 (or .6):
m=client1
With 2:4.15.13+dfsg-0ubuntu1.7:
m=
With 2:4.15.13+dfsg-0ubuntu1.8:
m=192.168.1.123
Conclusion:
This appears to be a regression in how Samba resolves %m. It may be
related to [Bug 2120811], which also affected other variables like %U.
For now, I’ve reverted to 2:4.15.13+dfsg-0ubuntu1.5, where everything
works as expected. I'm hoping for a fix or clarification in a future
release.
Best regards.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2123902
Title:
Regression in %m Variable Substitution: IP instead of name
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2123902/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
