samba rename bug - solution?

[Craig White]

On Sat, 2009-03-07 at 11:01 -0700, Eric Shubert wrote:
> Craig White wrote:
> > On Sat, 2009-03-07 at 09:42 -0700, Eric Shubert wrote:
> >> Craig White wrote:
> >>> On Sat, 2009-03-07 at 08:10 -0700, Eric Shubert wrote:
> >>>> Craig White wrote:
> >>>>> I would suspect that the version isn't as important here as making sure
> >>>>> that the filesystem is mounted with extended attributes.
> >>>>>
> >>>> Here's the pertinent part of my smb.conf:
> >>>>          map archive = no
> >>>>          map hidden = no
> >>>>          map read only = no
> >>>>          map system = no
> >>>>          store dos attributes = yes
> >>>>
> >>>> Here is the fstab entry:
> >>>> /dev/VolGroup00/LogVol00 /          ext3    defaults,user_xattr  1 1
> >>>>
> >>>> Any idea what is or might be wrong with the configuration?
> >>> ----
> >>> from the man page of smb.conf...
> >>>
> >>> under 'map read only'
> >>> If store dos attributes is set to yes then this parameter is ignored.
> >>> This is a new parameter introduced in Samba version 3.0.21.
> >>>
> >>> It seems to me that the upgrade of versions has nothing to do with this
> >>> issue.
> >>>
> >>> under store dos attributes (S)
> >>>
> >>> If this parameter is set Samba attempts to first read DOS attributes
> >>> (SYSTEM, HIDDEN, ARCHIVE or READ-ONLY) from a filesystem extended
> >>> attribute, before mapping DOS attributes to UNIX permission bits (such
> >>> as occurs with map hidden and map readonly). When set, DOS attributes
> >>> will be stored onto an extended attribute in the UNIX filesystem,
> >>> associated with the file or directory. For no other mapping to occur as
> >>> a fall-back, the parameters map hidden, map system, map archive and map
> >>> readonly must be set to off. This parameter writes the DOS attributes as
> >>> a string into the extended attribute named "user.DOSATTRIB". This
> >>> extended attribute is explicitly hidden from smbd clients requesting an
> >>> EA list.
> >>> On Linux the filesystem must have been mounted with the mount option
> >>> user_xattr in order for extended attributes to work, also extended
> >>> attributes must be compiled into the Linux kernel.
> >>> Default: store dos attributes = no
> >>>
> >>> I gather that with store dos attributes set to yes, then a file on Linux
> >>> would appear to be something like rwxrwxr_x (depending upon your create
> >>> mask) but the dos attribute itself is read only. I think that if the
> >>> file is copied as r_xr_xr_x then the dos attribute setting is probably
> >>> not going to help.
> >>>
> >>> Your configuration seems reasonable to me. There are a couple of things
> >>> I would check. The first thing I would probably do is up the log level
> >>> to 10 to get an extremely verbose log of the error which may present a
> >>> clue. The second thing I would check is renaming a 'read only' file from
> >>> other standard types of Windows programs such as the Windows Explorer
> >>> and perhaps the dos rename utility because I wonder if the cygwin rsync
> >>> actually respects the dos attributes.
> >>>
> >>> Craig
> >>>
> >> I should have mentioned that I did test other windows ways of renaming, 
> >> both to local and samba files.
> >> .) explorer rename of non-readonly local file just does it
> >> .) explorer rename of readonly local file gives warning, then does it
> >> .) ren command of non-readonly local file just does it
> >> .) ren command of readyonly local file just does it
> >> .) explorer rename of non-readonly smb file just does it
> >> .) explorer rename of readonly smb file gives warning, then does it
> >> .) ren command of non-readonly smb file just does it
> >> .) ren command of readonly smb file fails "permission denied"
> >>
> >> Thanks for the idea on logging, I'll try that and see what it gives.
> > ----
> > might be useful to look at the permissions of the file that gave
> > .) ren command of readonly smb file fails "permission denied"
> > 
> > from Linux - i.e. did the owner/group have write permissions?
> > 
> > Craig
> > 
> 
> Yeah, linux permissions look fine (rw for owner,group).
----
I gather that the problem is simply the tool you are using to manipulate
the file since explorer is capable of renaming the readonly file albeit,
with warning. I suspect that the rsync/cygwin combo is incapable of
making a useful response to smb alert message. Perhaps some flag setting
in rsync on cygwin allows a '--force' but that just seems to be a very
ugly hack.

Myself, I would still use robocopy.exe for all Windows file operations
if sophisticated ACL settings are involved.

Craig