enterprise-support team mailing list archive

[Andreas Hasenack <2123902@xxxxxxxxxxxxxxxxxx>]

** Description changed:

+ [ Impact ]
+ 
+  * An explanation of the effects of the bug on users and justification
+    for backporting the fix to the stable release.
+ 
+  * In addition, it is helpful, but not required, to include an
+    explanation of how the upload fixes this bug.
+ 
+ [ Test Plan ]
+ 
+  * 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.
+ 
+  * 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?
+ 
+  * 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 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
+ 
+  * 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
+ 
+ 
+ [ 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
+   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).
+     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.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:
+     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
+     /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.

** Also affects: samba (Ubuntu Jammy)
   Importance: Undecided
       Status: New

** Changed in: samba (Ubuntu Jammy)
       Status: New => In Progress

** Changed in: samba (Ubuntu Jammy)
     Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: samba (Ubuntu)
       Status: In Progress => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Server/Client Support Team, which is subscribed to samba in Ubuntu.
Matching subscriptions: Ubuntu Server/Client Support Team
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