Craig White wrote: > 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. No, the 'tool' being used is the CLI "ren" command. Part of standard dos. It's easily reproducible. See https://bugzilla.samba.org/show_bug.cgi?id=6173 > Myself, I would still use robocopy.exe for all Windows file operations > if sophisticated ACL settings are involved. That might end up being a better choice. I wouldn't call the read-only bit a sophisticated ACL setting though. ;) > Craig > -- -Eric 'shubes' --------------------------------------------------- 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