I am at my wits end on this one. Ever since I upgraded to samba3x (present version 3.5.10-0.110.el5_8) in preparation for adding a Win 7 client, my WinXP client can no longer find their roaming profiles nor can they assign their home shares to a drive at login. Logins and authentication work just fine and I can see the home and profile shares from the Win XP client after login. My smb.conf file contains (here are some essential snippets):
# the login script name depends on the machine name ; logon script = %m.bat # the login script name depends on the unix user used ; logon script = %u.bat logon script = logon.bat # disables profiles support by specifing an empty path ; logon path = logon path = \%L\profile%u%m logon home = \%L%u logon drive = H:
[homes] path = /mnt/home/%u comment = Home Directories browseable = no writable = yes valid users = %S guest ok = no inherit permissions = yes
[profile] path = /mnt/home/profile browseable = no writeable = yes default case = lower preserve case = no short preserve case = no case sensitive = no hide files = /desktop.ini/ntuser.ini/NTUSER.*/ write list = @smbusers @smbadmins create mask = 0600 directory mask = 0700 csc policy = disable profile acls = yes
I enabled debuging and from what I can tell the %u variable is not getting properly evaluated. For example for the homes share:
[2012/08/01 00:28:19.471215, 3] smbd/password.c:282(register_existing_vuid) register_existing_vuid: User name: snichols Real name: [2012/08/01 00:28:19.471240, 3] smbd/password.c:292(register_existing_vuid) register_existing_vuid: UNIX uid 501 is UNIX user snichols, and will be vuid 102 [2012/08/01 00:28:19.472336, 3] smbd/password.c:223(register_homes_share) Adding homes service for user 'snichols' using home directory: '/mnt/home/snichols' [2012/08/01 00:28:19.472475, 3] param/loadparm.c:6287(lp_add_home) adding home's share [snichols] for user 'snichols' at '/mnt/home/%u'
Or for the profile service:
2012/08/01 00:28:19.488457, 1] smbd/service.c:1070(make_connection_snum) sasha (192.168.1.13) connect to service profile initially as user snichols (uid=501, gid=501) (pid 25876 2012/08/01 00:28:19.489251, 3] smbd/trans2.c:5100(call_trans2qfilepathinfo) call_trans2qfilepathinfo: TRANSACT2_QPATHINFO: level = 1004 [2012/08/01 00:28:19.489364, 3] smbd/filename.c:945(get_real_filename_full_scan) scan dir didn't open dir [%u] [2012/08/01 00:28:19.489399, 3] smbd/vfs.c:881(check_reduced_name) check_reduced_name [%u/sasha] [/mnt/home/profile] [2012/08/01 00:28:19.489437, 3] smbd/vfs.c:962(check_reduced_name) check_reduced_name: couldn't get realpath for %u/sasha [2012/08/01 00:28:19.489463, 3] smbd/filename.c:1184(filename_convert) filename_convert: check_name failed for name %u/sasha with NT_STATUS_ACCESS_DENIED [2012/08/01 00:28:19.489495, 3] smbd/error.c:80(error_packet_set) error packet at smbd/trans2.c(5129) cmd=50 (SMBtrans2) NT_STATUS_ACCESS_DENIED
The samba/linux user that successfully logged in is snichols. Does anybody have a clue as to why %u is not evaluating to the linux username snichols and is getting treated simply as the string %u? I am sure it is something to stupid, but damn if I can see it.
Hello Paul,
On Wed, 2012-08-01 at 01:39 -0600, Paul R. Ganci wrote:
logon path = \\%L\profile\%u\%m logon home = \\%L\%u logon drive = H:
The samba/linux user that successfully logged in is snichols. Does anybody have a clue as to why %u is not evaluating to the linux username snichols and is getting treated simply as the string %u? I am sure it is something to stupid, but damn if I can see it.
Perhaps the single backslashes being escapes for the following percent signs? Try doubling the backslashes, possibly the first two in the path as well.
Regards, Leonard.
On 08/01/2012 04:06 AM, Leonard den Ottolander wrote:
Hello Paul,
On Wed, 2012-08-01 at 01:39 -0600, Paul R. Ganci wrote:
logon path = \\%L\profile\%u\%m logon home = \\%L\%uPerhaps the single backslashes being escapes for the following percent signs? Try doubling the backslashes, possibly the first two in the path as well.
Thanks for the idea ... I gave this a try but it is not the issue. The path in the error message was different but no cigar. I am positive that the syntax specified above is correct for the /etc/samba/smb.conf file as it is documented this way all over the web. It really looks like there is a mapping missing somewhere. For example I am seeing:
2012/08/01 07:03:05.412614, 3] smbd/service.c:807(make_connection_snum) Connect path is '/mnt/home/profile' for service [profile] [2012/08/01 07:03:05.412655, 3] smbd/vfs.c:97(vfs_init_default) Initialising default vfs hooks [2012/08/01 07:03:05.412684, 3] smbd/vfs.c:122(vfs_init_custom) Initialising custom vfs hooks from [/[Default VFS]/] [2012/08/01 07:03:05.412806, 3] lib/util_sid.c:228(string_to_sid) string_to_sid: Sid @smbusers does not start with 'S-'.
I do have some linux groups smbusers, smbadmins, smbguests defined in /etc/group
smbusers:x:103:snichols,visitor smbadmins:x:107:root,ganci smbguests:x:108:
and mapped the group like so:
net groupmap list
Domain Users (S-1-5-21-2436759526-4149905533-814844971-513) -> smbusers Administrators (S-1-5-32-544) -> 100000 Domain Guests (S-1-5-21-2436759526-4149905533-814844971-514) -> smbguests Domain Admins (S-1-5-21-2436759526-4149905533-814844971-512) -> smbadmins Users (S-1-5-32-545) -> 100001
I even tried adding this /etc/samba/smb.conf entry:
# Unix users can map to different SMB User names username map = /etc/samba/smbusers
with /etc/samba/smbusers containing:
cat smbusers
# Unix_name = SMB_name1 SMB_name2 ... root = Administrator administrator admin nobody = guest pcguest smbguest snichols = snichols ganci = ganci visitor = visitor
None of it works.
Am 01.08.2012 09:39, schrieb Paul R. Ganci:
The samba/linux user that successfully logged in is snichols. Does anybody have a clue as to why %u is not evaluating to the linux username snichols and is getting treated simply as the string %u? I am sure it is something to stupid, but damn if I can see it.
The stage at which %u needs to be evaluated in this case is before the user authentication happens. You have to use %U instead of %u - this is not a security issue as having the wrong UNC path should (and probably will) be caught using ACLs.
Regards, Andreas
On 08/01/2012 09:13 AM, Andreas Rogge wrote:
Am 01.08.2012 09:39, schrieb Paul R. Ganci:
anybody have a clue as to why %u is not evaluating to the linux username snichols and is getting treated simply as the string %u?
The stage at which %u needs to be evaluated in this case is before the user authentication happens. You have to use %U instead of %u - this is not a security issue as having the wrong UNC path should (and probably will) be caught using ACLs.
Thank you so much for this bit of information. I have spent 3 days on this issue and now realize I was searching the web with the wrong question. As soon as I asked for the difference between %U and %u everything becomes clear. Apparently the use of %u as I have been using it for the last 5 years was deprecated and apparently with samba3x stops working altogether.
The documentation is not very clear about the difference between %u and %U. The best I could find is that %u evaluates to the Linux username and that %U evaluates to (in my case) the Win XP client username. These do not necessarily have to be the same. Therefore I always used the %u version believing I was trusting the Linux. Besides out of the box the smb.conf uses %u as I did. Live and learn I suppose.
I haven't fixed my configuration yet but from what I just learned today this solution is what I was searching for the last three days. Again thank you very much for the information.
On 08/01/2012 09:13 AM, Andreas Rogge wrote:
Am 01.08.2012 09:39, schrieb Paul R. Ganci:
anybody have a clue as to why %u is not evaluating to the linux username snichols and is getting treated simply as the string %u?
You have to use %U instead of %u - this is not a security issue as having the wrong UNC path should (and probably will) be caught using ACLs.
Well last night I implemented this change and indeed this fixed the Win XP problem. The domain users on the client Win XP box can indeed find their roaming profiles and properly sync them at logon/logoff time. However when I went to add a domain user to the first Win 7 Professional box added to the domain, that user only gets a local profile (i.e. a C:\Users\username instead of C:\Users\username.domainame) despite the fact the domain user has a roaming profile. I am sure this is a Win 7 client setup issue.
The best I have been able to do is copy a local profile from the Win 7 box for the domain user back to the Samba PDC. I then delete the domain user's local profile and could get the Win 7 client to read the profile from the Samba PDC on the domain user's next logon. Basically I can get the Win 7 client to create a new local profile from the profile found on the Samba PDC but on logoff the Win 7 client will not sync that profile with the Samba PDC and on subsequent logons only uses the local stored profile on the Win 7 box. It is like the Win 7 client policy is to use local profiles only and it uses the Samba PDC profile only as a default if the local profile doesn't exist. There is no subsequent profile synchronization at logon/logoff after the Win 7 local profile gets created.
Any suggestions to registry/policy settings to get roaming profiles to act as roaming profiles on a Win 7 Professional SP 1 box? I thought I ask here first as I am already on this list. Admittedly this might better belong on a Samba forum but I am guessing somebody out there has already run into this issue. Everything on the web says this should work but alas...
On 08/02/2012 09:07 AM, Paul R. Ganci wrote:
On 08/01/2012 09:13 AM, Andreas Rogge wrote:
Am 01.08.2012 09:39, schrieb Paul R. Ganci:
anybody have a clue as to why %u is not evaluating to the linux username snichols and is getting treated simply as the string %u?
You have to use %U instead of %u - this is not a security issue as having the wrong UNC path should (and probably will) be caught using ACLs.
Well last night I implemented this change and indeed this fixed the Win XP problem. The domain users on the client Win XP box can indeed find their roaming profiles and properly sync them at logon/logoff time. However when I went to add a domain user to the first Win 7 Professional box added to the domain, that user only gets a local profile (i.e. a C:\Users\username instead of C:\Users\username.domainame) despite the fact the domain user has a roaming profile. I am sure this is a Win 7 client setup issue.
The best I have been able to do is copy a local profile from the Win 7 box for the domain user back to the Samba PDC. I then delete the domain user's local profile and could get the Win 7 client to read the profile from the Samba PDC on the domain user's next logon. Basically I can get the Win 7 client to create a new local profile from the profile found on the Samba PDC but on logoff the Win 7 client will not sync that profile with the Samba PDC and on subsequent logons only uses the local stored profile on the Win 7 box. It is like the Win 7 client policy is to use local profiles only and it uses the Samba PDC profile only as a default if the local profile doesn't exist. There is no subsequent profile synchronization at logon/logoff after the Win 7 local profile gets created.
Any suggestions to registry/policy settings to get roaming profiles to act as roaming profiles on a Win 7 Professional SP 1 box? I thought I ask here first as I am already on this list. Admittedly this might better belong on a Samba forum but I am guessing somebody out there has already run into this issue. Everything on the web says this should work but alas...
Are you adding all of the required registry entries on the Win7 machines to have them join the domain?
On 8/2/2012 8:29 AM, Johnny Hughes wrote:
Are you adding all of the required registry entries on the Win7 machines to have them join the domain? http://wiki.samba.org/index.php/Windows7
Thanks, Johnny ... Yes I have added those register entries and was able to join the Win 7 box to the domain just fine. I was also able to create a domain user account. I can logon with that domain user account just fine. The domain user home directory gets connected properly to drive H: and I can see the \server\profile\user share just fine. The only thing that is not occurring is that the profile created on the Win 7 box is a local profile and not a roaming one with the caveat that if the a local Win 7 profile is not found it takes the one found on the \server\profile\user share as a default. It is like the Win 7 box is setup to use local profiles only even if the profile is a roaming one. There are register entries you can set to make this happen but they are not present in my registry from what I can see.
On 08/02/2012 08:07 AM, Paul R. Ganci wrote:
Any suggestions to registry/policy settings to get roaming profiles to act as roaming profiles on a Win 7 Professional SP 1 box? I thought I ask here first as I am already on this list. Admittedly this might better belong on a Samba forum but I am guessing somebody out there has already run into this issue. Everything on the web says this should work but alas...
Well after nearly a week of agony I finally have my Win 7 roaming profiles acting like roaming profiles. It tuns out that while trying to get %u (as opposed to %U) to work I also was playing with the Win 7 profiles. Apparently I managed to munge these registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\SidXXX\CacheNextLogon HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\SidXXX\RefCount
For the roaming profile to synchronize properly the CacheNextLogon REG_DWORD had to be set to 0x00000000 and the RefCount REG_DWORD to 0x00000001. After I fixed these to have the proper value my profiles began to synchronize properly with my Samba PDC. I don't even remember what web search found this little tidbit but I guess even a blind squirrel finds a nut every so often.
-
Andreas Rogge -
Johnny Hughes -
Leonard den Ottolander -
Paul R. Ganci