If nothing else using robocopy isolates the variable to samba. But I am curious what your rsync looks like -----Original Message----- From: plug-discuss-bounces@lists.plug.phoenix.az.us [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 - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss