samba - May 2000 - Problem: permissions for removing a file in a file system mounte d by smbmount

Hi,

I have got a problem with the semantics of file permissions on a file system
mounted by smbmount on a Linux box (kernel 2.2.14, Samba 2.0.6, and after
looking through the 2.0.7 announcement, it appears that the problem has not
been addressed there).

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.)

I think this is not consistent with the usual UNIX behaviour, where I can
remove a file (at least with "rm -f") whenever I have write permission
for
the *directory* containing the file. I do not need write permission for the
file itself.

All of this would not be a problem if I just wanted to remove some file by
hand. But there are programs that appear to rely on the UNIX behaviour. (In
my case it is CVS. I want to put a CVS repository on the smbmount'ed file
system, because regular backups are done for the NT server.)

Is there a solution for this problem by appropriate configuration? (But I
did not find anything about this in the smbmount man page.) Or should the
behaviour of smbmount be modified? Do you know a work-around?

Best regards, and many thanks for providing Samba,

Heribert Sch?tz.

[Heribert Sch?tz <Heribert.Schuetz@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.  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.
> (In my case it is CVS. I want to put a CVS repository on the
> smbmount'ed file system, because regular backups are done for the NT
> server.)
Go the other way.  Mount a Unix share from your PC at the beginning of
your backup batch file, and unmount it at the end.

Peter