samba rename bug - solution?

[Eric Shubert]

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).

-- 
-Eric 'shubes'