BASIC INFO
==========
distribution = gentoo
uname -a = Linux Zeus 2.6.18-suspend2-r1 #2 PREEMPT Sun Mar 4 21:41:00 CET 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
modinfo cifs | grep version =
version:        1.45
srcversion:     4D64B46EB6E08A6AD6F56B2
samba 3.0.24

SYMPTOMS
========
in /etc/fstab
Quote:
//Venus/D_ /mnt/D cifs
users,gid=smb,file_mode=0770,dir_mode=0770,iocharset=iso8859-15,credentials=/etc/samba/credentials
0 0
# Venus is a Windows XP home machine, sharing D_ using 'Simple Sharing' (which
as I understand gives rw access to anybody, including guest.)

Steps to reproduce:
(as some user on the client)
cd /mnt/D
mkdir test6
ls -ld test* # in previous attempts I had already created the other testx
directories
drwxrwx--- 1 root smb     0 Feb 28 21:50 test3/
drwxrwx--- 1 root smb     0 Feb 28 21:52 test4/
drwxrwx--- 1 root smb     0 Feb 28 21:52 test5/
drwxr-xr-x 2 root smb     0 Feb 28 21:52 test6/
ls -ld test* # I can repeat the command as many times as I want, without the
permissions of test6 being different from 755, although I had expected 770
# 755 is in fact the result of umask 0022 on the client 

ls -ld test6
drwxrwx--- 1 root smb 0 Feb 28 21:52 test6/
# WOW, permissions suddenly changed

ls -ld test*
drwxrwx--- 1 root smb 0 Feb 28 21:50 test3/
drwxrwx--- 1 root smb 0 Feb 28 21:52 test4/
drwxrwx--- 1 root smb 0 Feb 28 21:52 test5/
drwxrwx--- 1 root smb 0 Feb 28 21:52 test6/
# and they remain changed as of now !!

MY HYPOTHESIS ON THE PROBLEM
============================
I tried the above mentioned commands, but using different umasks on the
client. I saw that when a directory is created, the (incorrect) permissions
it gets are the ones specified by the umask, not the ones specified by the
dir_mask from the mount command. The problem lies in the fact that the same
thing does not happen with the user/group id. There, the options specified
in the mount command are appied immediately. This leads to a status where
permission for the creating user are applied to the userid of the mount
command instead.

In detail I think this happens:

1. The client creates a directory: the samba protocol sends that to the
server, who actually creates the directory using local rules (probably with
owner guest/everybody).

2. The cifs client remembers (caches) it created the directory with the
umask of local user, but forgets (not-cached) that uid, and applies the
mount specified uid instead. Therefore a umask specifying 'only the local
user may write' now effectively says 'only the userid specified on the mount
command may write'. This effectively prevents the creating user from
accessing its own directory. I believe this is a bug, and should be
corrected.
An ls -l command shows 2 hard links, which would correspond to the cached
info and the uncached info being not equal.

3. Only some commands require the client to query the server again. Only as
of that moment, does the client read from the server that the directory
exists, and that it should be presented with the permissions as specified in
the dir_mask. It throws away the incorrect cached info (thereby reducing the
number of links), and applies the permissions that match the uid in the
mount command, which now say 'users in the group (which happens to include
the creating user) have write access'

In my opinion, one of two possible behaviours should be implemented:

A. the client caches not only the umask permissions, but also the creating
user. As long as the server data has not been re-read, it looks as though
the creating user has access rights according to the umask. the mount
uid/gid is only applied when the mount dir_mask is applied.

B. permissions are not cached and dir_mask is applied immediately.

Maybe such a behaviour is already implemented, and it may be possible to
specify what the cifs client does by activating some option in the mount
command. However, I was unable to find any such option.