[Spam] [Samba] Write list problem

[Dale Schroeder]

Ron Garcia-Vidal wrote:
> I upgrade my Debian Samba packages from 3.0.14a-1 to 3.0.23c-1.  I
> experienced 2 problems, one was that certain shares were locking users
> out who were listed in the "Valid users" parameter, but not all shares
> were doing this.  I ran across a post that advised changing the
> parameter to "users" alone, omitting "valid"  This fixed it, but I'm not
> sure why.  WHen did this parameter change and why was it not rejecting
> on all the shares.  I could post more configuration info on this if needed.
>
> Now for the unsolved problem.  I have a share in which certain users get
> read-only access, and certain other users get r/w access, using the
> "write list" parameter.  After the upgrade, everyone was reduced to
> read-only access.  Here's the share definition:
>
> [danasFiles]
> comment = Whatever
> path=/path/to-files
> users="@dana" "@danaread"
> read only = yes
> force group="dana"
> force create mode=0660
> force directory mode=0770
> write list="@dana"
> browseable = no
>
> The box is a member of a domain, security is set to "domain" and it is
> authenticating via winbind.  The permissions on the filesystem are set
> properly and this share definition was working perfectly under
> 3.0.14a-1.  I can send log output if needed.  Any ideas?
>   

If these are domain groups, perhaps this explains your problem:

 ===============================
 Release Notes for Samba 3.0.23b
 Aug 7, 2006
 ===============================

Member servers, domain accounts, and smb.conf

=============================================

Since Samba 3.0.8, it has been recommended that all domain accounts 
listed in smb.conf on a member server be fully qualified with the 
domain name.  This is now a requirement.  All unqualified names are 
assumed to be local to the Unix host, either as part of the server's 
local passdb or in the local system list of accounts (e.g. /etc/passwd 
or /etc/group).

The reason for this change is that smbd has transitioned from
access checks based on string comparisons to token based
authorization.  All names are resolved to a SID and then verified
against the logged on user's NT user token.  Local names will
resolve to a local SID, while qualified domain names will resolve
to the appropriate domain SID.  

If the member server is not running winbindd at all, domain 
accounts will be implicitly mapped to local accounts and their
tokens will be modified appropriately to reflect the local 
SID and group membership.

For example, the following share will restrict access to the
domain group "Linux Admins" and the local group srvadmin.

[restricted]
	path = /data
	valid users = +"*DOMAIN*\Linux Admins" +srvadmin

Note that to restrict the [homes] share on a member server to the 
owner of that directory, it is necessary to prefix the %S value 
to "valid users".

[global]
	security = {domain,ads}
	workgroup = DOM
	winbind separator = +
[homes]
	valid users = *DOM*+%S


Hope it works,

Dale