Samba and access right

[Lutz_4]

Hello

I have strange things on file moving by using samba ....
I have a destination directory (we can call it DEST) that has the SGID set and I force the file creation mode on 664
when I copy a file from one samba dir to another one (into my DEST dir)everything is set properly
But when I make a cut paste ... it takes the original right of my file!!!both SGID and samba config are ignored !!!????

is that normal ? is there a way to avoid that ?

thx

mathieu

[Steven E. Protter]

I am not sure I totally understand.

Can you provide a look at the permissions before and after.

Samba should work, if its in user based authentication mode off the default user umask settings, though this can probably be overridden in the smb.conf file.

You might want to provide the smb.conf file as an attachement to assist me and others in resolving your issue.

SEP

[Lutz_4]

Ok here are some complements :
the smb.conf file :

[global]
workgroup =
netbios name =
server string = HP File Server %h (%v)
interfaces = XXX.XXX.XXX.80
security = SERVER
update encrypted = Yes
password server = XXX.XXX.XXX.17
syslog = 0
log file = /var/opt/samba/log.%m
max log size = 1000
local master = No
ldap ssl = no
read only = No
dos filetime resolution = Yes


[file_data_rw]
comment = file access read write
path = /data/file
valid users =
force group = DESTgrp
create mask = 0664
force create mode = 0664
directory mask = 0775

so within /data/file I've 2 dirs : dir1 and DEST

DEST has rwx rws r_x group: DESTgrp

in dir1 I have a toto file with rights :
toto : rw- rw- --- group TOTOgrp

when I copy the file (over samba) from dir1 to DEST, my toto file gets :
toto : rw- rw- r-- group : DESTgrp
by doing a cut and past I got
toto : rw- rw- --- group TOTOgrp

that's wy issue ....

[Steven E. Protter]

Interesting,

security = SERVER
update encrypted = Yes
password server = XXX.XXX.XXX.17

It could be a problem on the password server. Users are being identified on that server. If its a Unix server here is a possible issue.

umask on the password server.
Numeric UID or GID is not the same for the same user on both machines.

Example:

user shcmo uid 501 gid 512 on servera
user schmo uid 503 gid 534 on serverb

The OS and CIFS/Samba use numbers and the umask or group umask settings on serverb need to be checked and are creating the results you are getting.

As a rule of thumb I try to make sure the numeric user ids and group ids for a given user are the same on ALL systems I administer.

This can be done manually or with an openldap server.

The samba log files may provide clues as to what is happening here.

fail -f

Then create the problem. See if there is a clue in there.

SEP

[Lutz_4]

Ok,

I'll have a look on the log files....
but unfortunately the passwd server is an Win server that's not administrated by myself :(

[Geoff Wild]

Allright - which version of Samba?

I strenuously recommend version 3 (the one from HP of course)...


You mean when you drag and drop the file - the permissions are okay?

But a ctlr x then ctrl v they are not?

Rgds...Geoff

[Lutz_4]

So
ctrl C + ctrl V applies the samba + unix rules so it's ok
ctrl X + ctrl V or drag& drop does not ... it keeps the original file rights.....

I have Samba version
3.0.5 based HP CIFS Server T.30 PV 02


By having a look in the log when I make a cut/paste or a copy/paste on a share called TEST it tells me :
couldn't find service TES ....
By renaming the share the error be the same, that's all concerning the error I can see :/

[Stefan Schulz]

Hi,

afaik this is a windows behavior. We have a windows directory to transfer data between different departments. The rights are set so that you can read everything thats in your departments subdir. And you are able to copy stuff to any other departmenst directory. But you cant read whats in the other departments subidir unless it is copied there by yourselfe.

We have the effect that this works as designed as long as you copy the files. But if you move the files the rights are not convertet correctly.

Unfortunately we haven't found a workaround. So the users have to make sure the copy not move the files.

Regards Stefan

[Lutz_4]

What a pitty, I really hate those kinds of security holes !!!

Why do you think it comes from Win world?
I wished there were some samba or CIF patch that correct this issue ...

[Stefan Schulz]

Hi Lutz,

i think this is a pure Windows behavieor because we see the effect you described on a Windows share not a Samba/CIFS share.

This directory i mentioned above resides on a Windows 2000 Server.

Hope this helps

Regards Stefan