Unix permissions, groups, etc as forced by Samba

[Andy Bakun]

> The systems in question are running Samba on Sun or Linux servers.
> Files are accessed via Unix clients using NFS and SMB on Win 95 machines.
>
> 1) When a user edits a file on their share; the group and file perms
>    get clobbered.
>
>    This is a problem when 2 users are sharing write access to a file via
>    groups on Unix; except that when the file is modified vis a SMB share
>    the group ownership gets reset to whichever user edited it and then
>    the other user(s) are unable to edit  the file.

The main problem is that when you "edit" a file with windows from some
applications, you aren't "editing" it in the UNIX sense of "editing".  Rather
than open the file, truncate it, and put the new contents in it (which is the
perfered method of "editing" file contents on UNIX, for the reason that you want
to keep the permissions on the files), windows will create a temporary file, put
the contents in there, and then do some fancy footwork with file renaming and
deleting to make it look like a single file was edited.

In light of this, you have to take into account that files are going to be
created during the "editing" stage, so you have to setup permissions on the
UNIX/samba side to give *new files* the permissions you want (even though it may
be the case that *new* files should not be an issue).

> Solution:
>
> Is there any way to totally disable Samba forcing / masking file permissions
>   and group information?

I think what you want to do is force samba to give certain file permissions, not
disable this ability.  If you don't mind home directories being totally
readable, for your [homes] share, use force create mode and force directory
mode.  Home directories being totally readable is not usually a problem when the
clients are only SMB, because users can not access each other's home dirs unless
you explictly create a share bound to, say, /home.  This may be a problem for
your NFS/Unix users.

> All I want is the owner/group/perms to default the way that they do when
>   someone creates/edits the file as a user on the Unix box.

You can't, because of microsoft's idea of "editing a file".  Notepad.exe doesn't
seem to be a problem (with file user/group ownership, but samba mapping the
archive bit to +x may be an issue (see also the 'map archive', 'map hidden' and
'map system' parameters)), but Office applications are especially bad, and I
suspect that your users are using Office (or some other, no offense, brain dead
application) to create their publicly accessible HTML files?

> Having to use multiple shares to force u+rw as opposed to u+rw,o+r on the
> ~ vs ~/public_html directories is inane.  It utterly confuses the Win 95
> users.

I've solved problems like this using samba-fu (available for 2.1) or close
command (something I cooked up for 2.0.x) to change the permissions on files if
they are in certain places.  Obviously not the ideal way to deal with this.  Or
you could use a cron job to check perms on files in ~/public_html.
Another method, but not the safest, is to start up your web server as a new
group, then make all the public_html directories sticky to that group.
This would be a lot easier if you only had users accessing files from one
location (SMB or NFS) not both.

Perhaps another method might be to rethink your share structure.  Rather than
try to make everything equlivent on both the UNIX/NFS and SMB sides, make the
SMB layout a subset of the UNIX layout: make the [homes] share map to a
subdirectory of the user's UNIX home directory, not the home directory itself.
Make a [public_html] share that maps to ~/public_html.  That way, the win95 only
users won't get confused: there is only one public_html visible to windows
clients.  Since these are different shares, you can use force mode/force group
only on those UNIX subdirs.
I've done something similar in order to reduce confusion and reduce the amount
of time it takes windows users to find files... works great.

Andy.