Bug 581 - %u and %H variable substitution don't work for login path
Summary: %u and %H variable substitution don't work for login path
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Domain Control (show other bugs)
Version: 3.0.0
Hardware: All Linux
: P3 major
Target Milestone: 3.0.1
Assignee: Gerald (Jerry) Carter
QA Contact:
Depends on:
Reported: 2003-10-07 06:59 UTC by Joe Frisbie
Modified: 2005-11-14 09:27 UTC (History)
0 users

See Also:

smb.conf (1.59 KB, text/plain)
2003-10-07 07:03 UTC, Joe Frisbie
no flags Details
Log level 10 (296.45 KB, text/plain)
2003-10-07 07:04 UTC, Joe Frisbie
no flags Details
The name of the directory created (83 bytes, text/plain)
2003-10-07 07:07 UTC, Joe Frisbie
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Frisbie 2003-10-07 06:59:00 UTC
The %u and %H variable substitutions are not expanded in the "login path" 
parameter. This makes it difficult to setup user profiles.
Comment 1 Joe Frisbie 2003-10-07 07:03:15 UTC
Created attachment 184 [details]

(Note it doesn't matter which way slashes go)
Comment 2 Joe Frisbie 2003-10-07 07:04:49 UTC
Created attachment 185 [details]
Log level 10 

It seems to know about the user (jf/742) before it does the filename expansion.
Comment 3 Joe Frisbie 2003-10-07 07:07:07 UTC
Created attachment 186 [details]
The name of the directory created
Comment 4 Joe Frisbie 2003-10-07 07:34:36 UTC
The same behavior happens if tdbsam is used as the passdb backend instead of 
ldapsam. And there no sambaHomePath, sambaHomeDrive, sambaLogonScript or 
sambaProfilePath attributes in the ldap directory.
Comment 5 Gerald (Jerry) Carter 2003-11-04 19:46:51 UTC
did this work under 2.2?  %U should be used in this situation 
over %u.  
Comment 6 Gerald (Jerry) Carter 2003-11-07 11:06:39 UTC
btw...this is invalid:

    logon path = //%L/profiles/%u_%m_%H_%a

Use a UNC path (\'s) instead.
Comment 7 Gerald (Jerry) Carter 2003-11-07 11:09:26 UTC
We will not expand %H in the logon path
since it would require a getpwnam() at 
a place in code where we have purposely avoided it.

Marking as won't fix.
Comment 8 Gerald (Jerry) Carter 2005-11-14 09:27:19 UTC
database cleanup