Problems with "Read Only" on a Samba share from Windows machines

Question

We have a Ubuntu 10.04 Server that has a bunch of Samba shares on it that Windows workstations connect to. Each Windows workstation has a valid username/password to access the shares, which have restricted access governed by Samba.

The problem we are experiencing is that Samba doesn't seem to be able to mimic the Windows way of handling "Read Only" attributes.

Say I have two users, UserA and UserB, both a group called Staff - UserA creates a file that is readable/writeable by the group (ie. chmod rwxrwx---). If UserA then sets the "Read Only" flag, this changes the permissions to r-xr-x--- (i.e. no write for anyone).

As UserB is in the same group as UserA, they should be able to remove the "Read Only" permission - however, they can't as Samba won't allow it.

Is there a way to force Samba to allow users within the same group to remove the "Read Only" from a file not created by them?

Edit:
The Samba smb.conf is as follows:

The share is defined in the smb.conf as:

[global]
    log file = /var/log/samba/log.%m  
    passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .  
    obey pam restrictions = yes  
    map to guest = bad user  
    encrypt passwords = true  
    passwd program = /usr/bin/passwd %u  
    passdb backend = tdbsam  
    dns proxy = no  
    netbios name = ubsrv  
    server string = ubsrv  
    unix password sync = yes  
    os level = 20  
    syslog = 0  
    usershare allow guests = yes  
    panic action = /usr/share/samba/panic-action %d  
    max log size = 1000  
    pam password change = yes  
    workgroup = workgroup  

[Projects]  
    valid users = @Staff   
    writeable = yes  
    user = @Staff  
    create mode = 0777  
    path = /srv/samba/Projects  
    directory mode = 0777  
    store dos attributes = Yes  

The folder itself looks like this:

ls -l /srv/samba/
drwxrwxrwx 2 nobody Staff 4096 2010-11-04 10:09 Projects

Thanks in advance,
Matt

Solution

We need more info as to how the shares are set up. A printout of the share definitions would help. Are you using ACL's or defining the share permissions from within the share definition? What do you mean by "setting the read only flag"? You mean right clicking on the file and checking the Read Only box? If so, that's not the best way to go, and you should look into implementing ACL's. Windows XP's filesystem is heavily dependent on them, and SAMBA can work with them perfectly.

Comments

[fistameeny]

I've updated the original post with the Samba config. I am defining the permissions from the share definition. Yes, "setting the read only flag" means right clicking on the file and ticking the box - this method can't be changed, as it's actually carried out automatically by a piece of software to stop users working on a file. Therefore, I can't simply alter permissions to make it work - the "read only" tickbox needs to be made to work

[churnd]

Then I'm not sure. I want to say that your create & directory modes are conflicting with permission creation & the POSIX permissions on the server. Who is the owner of the file in question? Nobody? I would do some reading in the SAMBA Documentation to see how SAMBA interprets that read-only checkbox.

[fistameeny]

A quick fix seems to be to create a generic user (e.g. StaffMember) and use the "force create" syntax to make all files created/edited by chown'ed by that user. This means that all users on the network are pretending to be same when opening/editing files. Not ideal, but it does sort of work

[churnd]

The fact that the generic user works reinforces my theory about the POSIX problem. The default umask on most unix systems is 0002 or 0022, either way does not support group write permission by default. I think what's happening here is that the read only change is making the file to where it is not writable at all, and the only person who can change that is either root or the owner. That's another reason why ACL's are nice, because they provide a workaround with the ownership limitations.