Just upgraded to Samba 3.0.2 (from 3.0.0) using up2date in RedHat Enterprise
Linux 3.0 and had to backout and return back to Samba 3.0.0 as our msdfs shares
were broken due to the %U not being substituted in the 'path' entry.
Our main dfs share is:
comment = Links to shares for %U
root preexec = /usr/local/bin/user_dfsroot %U
path = /home/%U/.dfsroot
msdfs root = yes
The "user_dfsroot" looks up in LDAP which dfs links should be setup for the user
and creates them in a dir under the user's home dir (eg
/home/username/.dfsroot/). The 'path' part then points there to allow each
user's mapped drive to have different contents based on what they should have
Problem is that in Samba 3.0.2 it seems that the %U is not being substituted
correctly, instead just sets it to an empty string (I also tested %u and %H
which had the same effect)
Samba log file snippit(debug level 4):
[2004/02/24 08:31:42, 3] smbd/vfs.c:vfs_init_default(203)
Initialising default vfs hooks
[2004/02/24 08:31:42, 4] smbd/vfs.c:vfs_ChDir(654)
vfs_ChDir to /home//.dfsroot
[2004/02/24 08:31:42, 3] msdfs/msdfs.c:create_conn_struct(105)
create_conn_struct: Can't ChDir to new conn path /home//.dfsroot. Error was No
such file or directory
[2004/02/24 08:31:42, 3] smbd/error.c:error_packet(94)
error string = No such file or directory
[2004/02/24 08:31:42, 3] smbd/error.c:error_packet(118)
error packet at smbd/trans2.c(3301) cmd=50 (SMBtrans2)
[skip a few lines, but in the same second:]
[2004/02/24 08:31:42, 4] smbd/reply.c:reply_tcon_and_X(278)
Client requested device type [?????] for share [SHARELINKS]
[2004/02/24 08:31:42, 3] lib/access.c:check_access(313)
check_access: no hostnames in host allow/deny list.
[2004/02/24 08:31:42, 2] lib/access.c:check_access(324)
Allowed connection from (10.20.100.4)
[2004/02/24 08:31:42, 3] smbd/service.c:make_connection_snum(543)
Connect path is '/home/iispbet/.dfsroot' for service [sharelinks]
[2004/02/24 08:31:42, 4] rpc_server/srv_srvsvc_nt.c:get_share_security(217)
get_share_security: using default secdesc for sharelinks
This shows that the msdfs part is unhappy, but it is still treated okay as a
normal share. The user sees the 'folders' but as Samba is no longer treating
this as an msdfs root, clicking on the folders just triggers a window error.
sorry for the spam. Should have updated everything at once.
patch for bug 417 fixed this one as well.
Post 3.0.3pre1 though.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.