I am migrating from my "old" 2.2.7 samba server to a newer server runnig
3.0.20a and everythig is working except the [homes] share. The server
(FILE-CABINET) is a member of the domain, security is set to ADS and, as
far as I can tell, kerberos is working. The program wbinfo returns a
list of users and groups like it should. getent passwd returns first my
local passwd file and then the list of windows users. nscd is off.
authentication seems to be working:
$ sudo wbinfo -a scarville%<password>
plaintext password authentication failed
error code was NT_STATUS_NSUCH_USER (0xc0000064)
error messsage was: No such user
Could not authenticate user scarville%<passwordwith plaintext password
challenge/response password authentication succeeded
I'm currently testing from a Window 2003 terminal server and, If I use
run->\\file-cabinet I can see all the listed shares and all _except_ the
home directory are accessible.
Usually a few minutes with Google is all I need to solve Samba problem
but not this time.
Samba version: 3.0.20a
I have in nsswitch.conf:
passwd: files winbind
shadow: files winbind
group: files winbind
in smb.conf:
[global]
unix charset = LCALE
workgroup = TTALFLD
realm = TTALFLD.CM
netbios name = FILE-CABINET
security = ADS
encrypt passwords = yes
lanman auth = no
lm announce = no
min protocol = NT1
username map = /etc/samba/smbusers
log level = 10
syslog = 0
server string = Main File Server
hosts allow = 192.168.124. 127.
log file = /var/log/samba/%m.log
max log size = 50
smb ports = 139
name resolve order = wins bcasts hosts
wins server = 192.168.124.10
socket options = TCP_NDELAY SRCVBUF=8192 SSNDBUF=8192
load printers = No
idmap uid = 10000-20000
idmap gid = 10000-20000
admin users = stephen, paul
[netapps]
comment = Network Applications
path = /export/netapps
force user = procman
force group = users
read only = No
[common]
comment = Common Files
path = /export/common
force group = users
read only = No
create mask = 0775
force create mode = 0664
directory mask = 0775
force directory mode = 0775
[public]
comment = Public Files
path = /export/public
force user = procman
force group = users
read only = No
create mask = 0774
[homes]
comment = Home Directory
path = /export/private/%S
hide dot files = yes
valid users = %S
read only = No
browseable = No
-- Stephen

I'm currently testing from a Window 2003 terminal server and, If I use
run->\\file-cabinet I can see all the listed shares and all _except_
the home directory are accessible.

[homes]
comment = Home Directory
path = /export/private/%S
hide dot files = yes
valid users = %S
read only = No
browseable = No

Is it possible that /export/private/%S doesn't exist? (i.e. %S isn't
what you're expecting it to be?)

If you set the path to /tmp or something, does that make the share
appear?

I'm just wondering whether %S is of the form "username" or
"DMAIN\username", and whether case sensitivity is important. I'm
guessing it is, being in a UNIX path name.

Cheers,
Adam.

Adam Nielsen wrote:
>>I'm currently testing from a Window 2003 terminal server and, If I use
>>run->\\file-cabinet I can see all the listed shares and all _except_
>>the home directory are accessible.
>>
>>[homes]
>comment = Home Directory
>path = /export/private/%S
>hide dot files = yes
>valid users = %S
>read only = No
>browseable = No

Is it possible that /export/private/%S doesn't exist? (i.e. %S isn't
what you're expecting it to be?)

If you set the path to /tmp or something, does that make the share
appear?

All the shares appear, I just cannot access the home directory. I tried
changing the share path to /tmp with the same results. After playing
around a bit I was able to get some useful messages:

[2006/05/14 22:41:16, 4] smbd/reply.c:reply_tcon_and_X(618)
Client requested device type [??] for share [SCARVILLE]
[2006/05/14 22:41:16, 5] smbd/service.c:make_connection(776)
making a connection to 'homes' service [SCARVILLE] created at session
setup time
[2006/05/14 22:41:16, 3] lib/access.c:check_access(313)
check_access: no hostnames in host allow/deny list.
[2006/05/14 22:41:16, 2] lib/access.c:check_access(324)
Allowed connection from (192.168.124.134)
[2006/05/14 22:41:16, 10] lib/username.c:user_in_list(583)
user_in_list: checking user TTALFLD\scarville in list
[2006/05/14 22:41:16, 10] lib/username.c:user_in_list(587)
user_in_list: checking user |TTALFLD\scarville| against |scarville|
[2006/05/14 22:41:16, 2] (318)
user 'TTALFLD\scarville' (from session setup) not permitted to
access this share (scarville)
[2006/05/14 22:41:16, 3] smbd/error.c:error_packet(147)
error packet at smbd/reply.c(626) cmd=117 (SMBtconX)
NT_STATUS_ACCESS_DENIED
[2006/05/14 22:41:16, 5] lib/util.c:show_msg(454)
[2006/05/14 22:41:16, 5] lib/util.c:show_msg(464)
size=35
smb_com=0x75
smb_rcls=34
smb_reh=0

I changed the section to:

[homes]
comment = Home Directory
path = /export/private/%U
hide dot files = yes
valid users = TTALFLD\%S
read only = No
browseable = No

And I can now access the directory but it's read-only

well, it's progress of a sort

I'm just wondering whether %S is of the form "username" or
"DMAIN\username", and whether case sensitivity is important. I'm
guessing it is, being in a UNIX path name.

Cheers,
Adam.

I changed the section to:

[homes]
comment = Home Directory
path = /export/private/%U
hide dot files = yes
valid users = TTALFLD\%S
read only = No
browseable = No

And I can now access the directory but it's read-only

well, it's progress of a sort

In that case the problem should be solved by changing/duplicating
'valid users = ' to 'write list = '

Cheers,
Adam.

Based on suggestions here and elsewhere I've made some changes. First
to [homes]:

[homes]
comment = Home Directory
path = /export/private/%U
hide dot files = yes
valid users = %S
write list = %S
read only = yes
browseable = No

I also changed the mapping in smbuser:

stephen = TTALFLD/scarville

I can now see and open all the shares which is the good news. The bad
news is that my home directory cannot be accessed by scarville -- my
windows username -- but only by my Unix username stephen. If I try to
open it as //file-cabinet/scarville:

2006/05/15 06:44:55, 0] smbd/service.c:make_connection(798)
pellucidar (192.168.124.232) couldn't find service scarville

but as //file-cabinet/stephen it works.

So, apparently, a logon script entry like "net use z: \\file-cabinet\%u"
will not work unless the UNIX and windows usernames are the same.

There are only a few persons in the shop whose UNIX and Windows username
are different but, unfortunately, one of them is the VP of IT who will
bitch incessantly about the "inconvenience". Not entirely unjustified
since it worked under 2.2.

Maybe I should just downgrade

valid users = %S
write list = %S
read only = yes

You'll probably need "read only = no", or what I believe is more
intuitive, "writable = yes" followed by the "write list" option.
You'll probably want to double check this, but as far as I'm aware the
existence of a "write list" option by definition forces anyone who's
not in the write list to have read-only access. The "valid users"
option will force anyone not in that list to get no access at all. I'm
not sure what effect it has by saying "these users have write access, oh
but the share is read only, so don't give anyone write access."

I also changed the mapping in smbuser:

stephen = TTALFLD/scarville

That might've confused things, because now it's like doing a search and
replace, so anywhere TTALFLD/scarville shows up, it'll be replaced
by "stephen" before parsing smb.conf. I assume this would also change
the meaning of %U and %S.

I can now see and open all the shares which is the good news. The
bad news is that my home directory cannot be accessed by scarville --
my windows username -- but only by my Unix username stephen. If I
try to open it as //file-cabinet/scarville:

2006/05/15 06:44:55, 0] smbd/service.c:make_connection(798)
pellucidar (192.168.124.232) couldn't find service scarville

but as //file-cabinet/stephen it works.

Yes, because connecting as TTALFLD/scarville would cause Samba to
chop off the domain name and create a share called 'scarville', but I'm
guessing that because of your username mapping, TTALFLD/scarville is
being changed to 'stephen' before Samba sees it, so you're effectively
connecting as the user 'stephen', which causes Samba to create your
home directory as 'stephen' too - Samba is no longer seeing 'scarville'
anywhere because the username map is replacing every occurrence of it
with 'stephen'.

So, apparently, a logon script entry like "net use z:
\\file-cabinet\%u" will not work unless the UNIX and windows
usernames are the same.

Does "net use z: /home" work? assuming you've configured the user's
home directory on the domain server.

There are only a few persons in the shop whose UNIX and Windows
username are different but, unfortunately, one of them is the VP of
IT who will bitch incessantly about the "inconvenience". Not
entirely unjustified since it worked under 2.2.

Well if nothing else, you could always create a couple of extra shares
for those users whose names are different - a bit messy yes, but at
least it'll work.

Cheers,
Adam.