samba - Nov 2005 - Guest account problem ... please help

I have an internal Samba installation where I have security=share, and have
everything going to a guest account, in which I've made as user called
"samba".  When connected to a samba share on my UNIX system, I can can
copy
and move files using my XP client, but I can't delete files?  I was
expecting Samba to follow the permissions of the user, which should be able
to delete these files because they are in a related group.  I've enclosed my
smb.conf.  The internal (guest) user I 'm using is called "samba",
and it's
default group is "dl4ub".  The files and the directory their in have
"dl4ub"
as their group.  Please help.

smb.conf:

[global]
     netbios name = spserv1
     server string = Samba
     os level = 255
     local master = yes
     preferred master = yes
     security = share
     username map = /etc/samba/users.map
     wins support = yes
     workgroup = SPS1
     socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 SO_KEEPALIVE
     log level = 1
     guest account = samba
     max xmit = 65535
     read size = 65536
     interfaces = net0
     bind interfaces only = yes
[NETLOGON]
     comment = Network Logon Service
     path = /etc/samba/netlogon
     guest ok = yes
     guest only = yes
     hosts allow = 192.1.1.
[unix]
     comment = unix
     force user = check
     force group = dl4ub
     create mode = 0000
     force create mode = 0660
     directory mode = 0000
     force directory mode = 0770
     path = /
     read only = no
     guest ok = yes
     guest only = yes
     hosts allow = 192.1.1.
     mangled names = no
[RDM-Ingenico]
     comment = RDM-Ingenico
     force user = check
     force group = dl4ub
     create mode = 0000
     force create mode = 0660
     directory mode = 0000
     force directory mode = 0770
     path = /u/ftprdm
     read only = no
     guest ok = yes
     guest only = yes
     hosts allow = 192.1.1.
     mangled names = yes
[g]
     comment = g
     force user = check
     force group = dl4ub
     create mode = 0000
     force create mode = 0660
     directory mode = 0000
     force directory mode = 0770
     path = /u/g
     read only = no
     guest ok = yes
     guest only = yes
     hosts allow = 192.1.1.
     mangled names = no
[web]
     comment = web
     force user = web
     force group = dl4ub
     create mode = 0000
     force create mode = 0664
     directory mode = 0000
     force directory mode = 0775
     path = /u/apache/htdocs
     read only = no
     guest ok = yes
     guest only = yes
     hosts allow = 192.1.1.
     mangled names = no

Thanks,

Rick

> When connected to a samba share on my UNIX system, I can can copy and
> move files using my XP client, but I can't delete files?  I was
> expecting Samba to follow the permissions of the user, which should
> be able to delete these files because they are in a related group.
If you 'su' to the guest user, can you delete the files with
'rm'?  That
would tell you whether it's a problem with your UNIX permissions or with
Samba.

It sounds like the directory containing these files doesn't have u+w
permission and/or isn't owned by the user trying to delete the files,
but it looks like you've already checked this.

Cheers,
Adam.

Hi Rick,
> It's as if the "samba" user is not even coming into play,
although
> I've taken measures to insure that's the user used for when
> connections are made to the Samba server.  Very strange.  What do you
> think?
Are you 100% sure you're logging in to the server as the correct user?
I had Samba set up to map to the guest user for a bad password which
got me.

You should be able to run "net status sessions" or "net status
shares"
to see who's actually connected to the share.  Hopefully this will be
the username you're expecting.  You could also try creating a file from
the Windows box (in a chmod 777 folder if necessary) - this new file
will tell you for sure what credentials Samba is using when connected
as that user.

Cheers,
Adam.

> This problem is so strange.  The permissions are not following the
> group I'm assigning.  It seems to be "hung" on the group
"group".
Since you have "force user = xxx" in many of your share definitions,
I'm assuming changing to these users via 'su' still allows you to
delete
files?
> I can copy to the directory okay, but I can't delete.  Is there some
> kind of Windows issue that is unique to deleting that is causing this?
Do you get the same behaviour when using "smbclient
//localhost/share"?

You could try running smbd in debug mode and see what it comes up with
when you attempt to delete a file - that may give you something to go
on.

Cheers,
Adam.

> Adam, I can delete the files with those force users - user.  UNIX
> "follows" the group, as it should and you would expect.
Ah, I see what you mean now by "following" the group.  I have a setup
here where although the groups are pulled from Active Directory, Samba
still "follows" the groups - i.e. the group permissions are honoured
for any user belonging to that group, whether it's their primary group
or not.

Given that you couldn't run "net status ..." before, what version
of
Samba are you running?  My only guess now is that perhaps it's an older
version (I'm running 3.0.20)

It is strange though, that logging on with smbclient as the same user
would allow you to delete the file - if this is the case I'd start
looking at the Windows side of things, because it's unlikely to be
Samba at fault if smbclient works.

If you right-click on a folder, choose Properties, click Advanced and
then go to the Effective Permissions tab, what are the permissions
listed as for some of the users?  Note that I think write access is
required to delete files, since when I do this the "Delete access"
checkbox is unticked, yet I can still delete files.

Cheers,
Adam.

Hi Rick,

Sometimes you can specify the username as "SERVER\user" however
I'm not
sure how well this works outside of a domain.

Is there any chance you could upgrade to the latest version of Samba to
see if the problem has been fixed?  I think that's the only thing left
to try.

Cheers,
Adam.