I've recently migrated my servers from debian sarge to debian etch, thus from samba 3.0.14a to samba 3.0.24.
I've deployed in my environment WPKG (http://wpkg.org/) using the WPKGClient: basically, a services running as local SYSTEM user run a js script that do some stuff, more notably install/remove software.
On sarge i was used to put software to install in a 'Software' share, and because was merely a public access share i've configured as:
comment = Software Vario
browseable = yes
path = /srv/Software
read only = yes
public = yes
nt acl support = no
force create mode = 0664
force directory mode = 2775
force group = ced
write list = root @ced
in what i call 'simple permission setup', eg. no ACL, use only base POSIX access types (ugo) and enforce permissions and group.
Guest access works flawlessy.
Switched to etch what i noted was that i have to remove 'nt acl support = no' (or put yes, it's the default) because whithout that the share was barely unaccessible as SYSTEM.
In one system (really, i've not understood why...) i was also forced to remove completely the 'simple permission setup' and enable full ACL support to have the SYSTEM user access the share. Permission on disk looks ok, or at least look equal to other setup that works.
If you know italian, you can also use as reference these thread:
Some more note:
a) if i try to access shares with some other local user (eg, Administrator account) guest access work flawlessy: eg, seems a trouble with the SYSTEM account
b) as suggested by Simo, i've removed DFS support that have bugs on .24
c) as stated, guest access works before and after upgrade, and still works for all apart SYSTEM
d) i've produced some log at level 10, if needed i can send along with full smb.conf files.
As suggested by simo, in next days, if i catch some spare time, i will try to isolate the smb.conf parameter that trigger this behaviour, enabling and disabling switches one by one.
many thanks to all.
I've moved to debian lenny (samba 3.2.5), revamped this bug with a subject change.
I've done some more test, and seems that there's some sort of incompatibility between the share parameters 'guest ok= yes' and 'force group'.
If i set 'guest ok = no', force group works as expected.
If i set 'guest ok = yes', force group work as expected if i use whatever user have legitimate access.
If i set 'guest ok = yes' and try to access as anonymous (guest access) i got deny access whatever group, +group, DOMAIN\group or +DOMAIN\group i use.
They are incompatible? If yes, why?
AFAI've understood the manpage, 'guest ok = yes' and 'force group = +DOMAIN\group' are exactly what i need, force write access with group DOMAIN\group for user that are in DOMAIN\group (and possibly not the primary one), keeping default readonly/guest access for others.
I hope i was clear, many thanks.
PS: some more hints, in italian: