samba - Mar 2010 - Permissions problem with Windows Vista / 7 clients, Debian Samba 3.4.7 server

I'm having a very strange permissions problem with Samba 3.4.7 (installed
via backports.org) running on Debian Lenny:

If a Windows 7 or Windows Vista client tries to use Windows Explorer to
access a user's home directory with permissions 0700, the client gets a
permission denied error.

If the directory is made world readable, it works.  (For one user, group
readable also works.  For another user, it does not.)

Accessing the same directory from the command prompt ("dir
\\server\username") instead of from Windows Explorer works.

Accessing the same directory from Windows Explorer in Windows XP works.

This problem started when we upgraded from Samba 3.2.5 to Samba 3.4.7.  With
Samba 3.2.5, our Vista users were fine, but Windows 7 was unable to connect
(login failed, apparently due to the NTLMv2 / 128-bit encryption limitations
that I read about online).

Here's a snippet from the log file:
[2010/03/15 15:09:58,  3] smbd/process.c:1273(switch_message)
  switch message SMBntcreateX (pid 10955) conn 0x884d9d0
[2010/03/15 15:09:58,  4] smbd/uid.c:256(change_to_user)
  change_to_user: Skipping user change - already user
[2010/03/15 15:09:58,  5] smbd/filename.c:148(unix_convert)
  unix_convert called on file ""
[2010/03/15 15:09:58,  5] smbd/filename.c:181(unix_convert)
  conversion finished "" -> .
[2010/03/15 15:09:58,  3] smbd/vfs.c:865(check_reduced_name)
  reduce_name [.] [/home/jkelley]
[2010/03/15 15:09:58,  3] smbd/vfs.c:974(check_reduced_name)
  reduce_name: . reduced to /home/jkelley
[2010/03/15 15:09:58,  5] smbd/files.c:103(file_new)
  allocated file structure 11470, fnum = 15566 (2 used)
[2010/03/15 15:09:58,  3] smbd/dosmode.c:149(unix_mode)
  unix_mode(.) returning 0700
[2010/03/15 15:09:58,  3] smbd/vfs.c:865(check_reduced_name)
  reduce_name [.] [/home/jkelley]
[2010/03/15 15:09:58,  3] smbd/vfs.c:974(check_reduced_name)
  reduce_name: . reduced to /home/jkelley
[2010/03/15 15:09:58,  4] smbd/open.c:1913(open_file_ntcreate)
  calling open_file with flags=0x0 flags2=0x0 mode=0700, access_mask = 0x81,
open_access_mask = 0x81
[2010/03/15 15:09:58,  5] smbd/files.c:474(file_free)
  freed files structure 15566 (1 used)
[2010/03/15 15:09:58,  5] smbd/open.c:2391(open_directory)
  open_directory: opening directory ., access_mask = 0x81, share_access 0x7
create_options = 0x0, create_disposition = 0x1, file_attributes = 0x0
[2010/03/15 15:09:58,  3] smbd/error.c:60(error_packet_set)
  error packet at smbd/nttrans.c(563) cmd=162 (SMBntcreateX)
NT_STATUS_ACCESS_DENIED

Josh Kelley

On Mon, Mar 15, 2010 at 3:24 PM, Josh Kelley <joshkel at gmail.com> wrote:
> I'm having a very strange permissions problem with Samba 3.4.7
(installed
> via backports.org) running on Debian Lenny:
>
> If a Windows 7 or Windows Vista client tries to use Windows Explorer to
> access a user's home directory with permissions 0700, the client gets a
> permission denied error.
>
> If the directory is made world readable, it works.  (For one user, group
> readable also works.  For another user, it does not.)
>
> Accessing the same directory from the command prompt ("dir
> \\server\username") instead of from Windows Explorer works.
>
> Accessing the same directory from Windows Explorer in Windows XP works.
>
> This problem started when we upgraded from Samba 3.2.5 to Samba 3.4.7.
> With Samba 3.2.5, our Vista users were fine, but Windows 7 was unable to
> connect (login failed, apparently due to the NTLMv2 / 128-bit encryption
> limitations that I read about online).
>
I managed to fix this problem.  I had been using a username map script since
Samba 3.0.24 to change "DOMAIN\username" to "username" so
that users
wouldn't have to SSH in to the (Winbind plus) Samba system as
DOMAIN\username.  Apparently, with Samba 3.4.7, this kind of username map is
no longer necessary, and it was keeping Samba from treating users as domain
users and properly resolving their SIDs.

The Samba logfile does say that this is happening (with references to the
Unix User domain and use of a S-1-22-1-... SID), but I had not looked at
that part of the logfile.

I really don't understand why username map is acting differently now, but
since disabling it seems to work, I'm happy.

-- 
Josh Kelley