RE: samba rename bug - solution?

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Bryan O'Neal
Date:  
To: 'Main PLUG discussion list'
Subject: RE: samba rename bug - solution?
If nothing else using robocopy isolates the variable to samba. But I am
curious what your rsync looks like

-----Original Message-----
From:
[mailto:plug-discuss-bounces@lists.plug.phoenix.az.us] On Behalf Of Craig
White
Sent: Saturday, March 07, 2009 8:52 PM
To: Main PLUG discussion list
Subject: Re: samba rename bug - solution?

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

---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss