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