samba rename bug - solution?

[Eric Shubert]

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'