I have a billing database that runs on a Faircom engine. I had set
things up initially with users accessing files in this directory with
their user accounts. However, only one person could enter data at a
time. I then created a seperate share for this directory and did a
force user= on it. I had thought that this worked, but of course users
never bothered to tell me that after a short period of time the problem
reemerged. I'm wondering what other tricks I might use here to eleviate
this problem.
The server is a LDAP PDC running 3.0.10. smb.conf. Tabs3 is the
database directory
global]
workgroup = FSKS
server string = Camarillo
interfaces obey pam restrictions = Yes
passdb backend = ldapsam:ldap://
log file = /usr/log/samba/%m.log
max log size = 50
acl compatibility = win2k
map acl inherit = Yes
server signing = auto
add user script = /var/lib/samba/sbin/smbldap-useradd.pl -a -m
'%u'
delete user script = /var/lib/samba/sbin/smbldap-userdel.pl '%u'
add group script = /var/lib/samba/sbin/smbldap-groupadd.pl -p
'%g'
delete group script = /var/lib/samba/sbin/smbldap-groupdel.pl
'%g'
add user to group script =
/var/lib/samba/sbin/smbldap-groupmod.pl -m '%u' '%g'
delete user from group script =
/var/lib/samba/sbin/smbldap-groupmod.pl -x '%u' '%g'
set primary group script =
/var/lib/samba/sbin/smbldap-usermod.pl -g '%g' '%u'
add machine script = /var/lib/samba/sbin/smbldap-useradd.pl -w
'%u'
domain logons = Yes
os level = 33
lm interval = 5
preferred master = Yes
domain master = Yes
wins server lock spin count = 4
ldap admin dn = cn=Manager,dc=fsklaw,dc=com
ldap filter = (&(uid=%u)(objectclass=posixAccount))
ldap group suffix = ou=groups
ldap idmap suffix = ou=Idmap
ldap machine suffix = ou=computers
ldap suffix = dc=fsklaw,dc=com
ldap user suffix = ou=users
idmap backend = ldap:ldap://
idmap uid = 10000-20000
idmap gid = 10000-20000
admin users = tms3
inherit permissions = Yes
inherit acls = Yes
write cache size = 262144
dos filemode = Yes
dos filetimes = Yes
[camarillo]
path = /usr/home/camarillo
read only = No
create mask = 0777
force create mode = 0777
force directory mode = 0777
guest ok = Yes
[www]
path = /usr/local/www
valid users = root
read only = No
[Profiles]
path = /usr/home/camarillo/open/Profiles
read only = No
guest ok = Yes
profile acls = Yes
hide files = /desktop.ini/
[tabs3]
path = /usr/home/camarillo/open/STI_Remote
force user = root
read only = No
create mask = 0740
force create mode = 0740
force directory mode = 0740
directory security mask = 0740
guest ok = Yes
veto oplock files = rmtfee.dat, rmtfee.idx
On Fri, 2005-04-08 at 13:10 -0700, Tom Skeren wrote:> [tabs3] > path = /usr/home/camarillo/open/STI_Remote > force user = root > read only = No > create mask = 0740 > force create mode = 0740 > force directory mode = 0740 > directory security mask = 0740 > guest ok = Yes > veto oplock files = rmtfee.dat, rmtfee.idxJust a quick note to others - this looks like a security nightmare - imagine a user connecting in with a unix client, as guest, and creating a setuid executable. I don't think we block that... ON the issue of database sharing, the issues are almost never related to permissions (a simple edit of text files will show what permission issues there are). Provided the users are all in a group with write permission (and possibly g+s set on the directory) it usually works pretty well. Instead, these are matters of locking - does this DB support multiple access on other network servers (win2k?). Avoiding oplocks is good for performance and stability, but if the underlying DB is getting exclusive locks, then you won't get far. What does smbstatus show? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.samba.org/archive/samba/attachments/20050411/a3cc0d68/attachment.bin