AW: Problem: permissions for removing a file in a file system mou nted by smbmount

[Heribert Schütz]

Hi,

thanks for your prompt reply.

Peter Samuelson wrote:
> [Heribert Schütz <Heribert.Schuetz at gsi-office.de>]
> > Consider the following case: I mount a share from an NT server on a
> > Linux box, which I then use at the Linux box. I create a file on that
> > partition and remove its write permissions. This happens whithin a
> > directory which does have write permission. When I now want to remove
> > the file, it does not work, but I rather get an error message that I
> > don't have the permission for that. (When I set write permissions for
> > the file again, then I can remove the file.)
> 
> Take it up with your file server vendor.  This is server-side behavior;
> perhaps they can provide you a patch.

I am afraid they will just say that their behaviour is in accordance
with normal SMB behaviour. And they are right so: The "Microsoft
Networks/OpenNET FILE SHARING PROTOCOL", Version 2.0 of November 7, 1988
says in section 5.10 that "Read only files may not be deleted, the
read-only attribute must be reset prior to file deletion."

On the other hand, on Unix deleting a file depends on the write
permission of its containing *directory*. For example, the GNU fileutils
info file says: "There are three kinds of permissions that a user can
have for a file: ... 2. permission to write to (change) the file.  For
directories, this means permission to create and remove files in the
directory. ..."

So there is obviously a semantic difference between Unix and SMB
behaviour. (Neither of these two semantics is "right" or "wrong". They
are both legitimate.)

It would be *wonderful* if samba were able to bridge that gap, i.e.,
if smbmount provided Unix-like behaviour to a Unix system. (Because
certain Unix programs rely on this behaviour.) After all, it is samba
which sits at the border between SMB and Unix.

> The only way to work around it
> at the client end would be for smbfs to issue explicit chmod commands
> prior to attempting to delete or rename files.  In my opinion this is a
> performance and complexity hit that isn't worth it.

I agree that there is some programming complexity. But it should not be
too much of a performance problem, because the chmod would only be
necessary if a first attempt to delete the file fails and the directory
has write permission.

Furthermore, the Unix-like behaviour might be optional:

- If you just want a file system, that is normally used from
  Windows, to be visible at a Linux machine, then you might prefer
  SMB-style semantics.
- If you usually use a file system on a Linux box and just use an
  NT box as a fileserver, then you probably prefer Unix-Style
  semantics.

(The latter is my situation. I am the only one working on a Linux
machine here in an "NT shop".)

Regards,

Heribert.