samba - Aug 2020 - smbclient mask command seems not to work the same way with recurse ON for mget and mput

A new update. Same behaviour with 4.6.16. Exact issue as Bug 1249.

Many thanks. Kind regards.

El lun., 24 ago. 2020 a las 12:23, LPC DPG (<lpcdpg at gmail.com>)
escribi?:
> Dear folks.
>
> Was hoping it had to do with the release, but have also tested in 4.4.16
> and the issue is also there. I am aware a RHEL/CEntOS based upon 6
> distribution is not the most up to date version I should test this on, as
> it also limits how easy is compiling most recent versions of Samba, but I
> assume though this is not a tricky test, and should work as documented in
> both 4.4 and 4.2 versions.
>
> Looking forward to reading your remarks.
>
> Many thanks in advance. Best regards.
>
> El vie., 21 ago. 2020 a las 12:25, LPC DPG (<lpcdpg at gmail.com>)
escribi?:
>
>> Dear folks.
>>
>> I am using smbclient 4.2.10 version (the one packaged for OEL 6,
>> samba4-client-4.2.10-15.el6.x86_64), and observing a weird behaviour of
the
>> tool.
>>
>> I've got a Linux local directorio, say /tmp/eraseme, with a couple
of
>> subdirectories in it, say a and b, each one containing a dummy file,
say
>> a/AM.xls and b/AT.xls
>>
>> If I run:
>> smbclient -d 30 -l /var/log/samba -m SMB3 -W "${d}" -U
"${u}" "${s}"
>> "${p}"
>> smb: \> lcd /tmp/eraseme
>> smb: \> recurse
>> smb: \> prompt
>> smb: \> mask *M.xls
>> smb: \> mput *
>>
>> it transfer both AM.xls an AT.xls files, which seems not to agree what
>> man page states:
>>
>> "       mask <mask>
>>            This command allows the user to set up a mask which will be
>> used during recursive operation of the mget and mput commands.
>>
>>            The masks specified to the mget and mput commands act as
>> filters for directories rather than files when recursion is toggled ON.
>>
>>            The mask specified with the mask command is necessary to
>> filter files within those directories. For example, if the mask
specified
>> in an
>>            mget command is "source*" and the mask specified
with the mask
>> command is "*.c" and recursion is toggled ON, the mget
command will retrieve
>>            all files matching "*.c" in all directories below
and
>> including all directories matching "source*" in the current
working
>> directory.
>>
>>            Note that the value for mask defaults to blank (equivalent
to
>> "*") and remains so until the mask command is used to change
it. It retains
>>            the most recently specified value indefinitely. To avoid
>> unexpected results it would be wise to change the value of mask back to
"*"
>> after
>>            using the mget or mput commands."
>>
>> Nonetheless, if I do it the other way around,
>>
>> smbclient -d 30 -l /var/log/samba -m SMB3 -W "${d}" -U
"${u}" "${s}"
>> "${p}"
>> smb: \> lcd /tmp/eraseme
>> smb: \> recurse
>> smb: \> prompt
>> smb: \> mask *M.xls
>> smb: \> mget *
>>
>> , mget does seem to honour the referred description, downloading only
>> AM.xls file to Linux.
>>
>> I have been looking in Google, but have seen no reference to similar
>> problems. I do assume hence whether I am doing something wrong, or
>> misinterpreting the manual, then I can't get it working.
>>
>> So I'd be really grateful if any of you who might have ever faced
>> something similar could share the experience, as I am really lost with
it.
>>
>> Thanks so much in advance. Best regards.
>>
>

On 24/08/2020 13:48, LPC DPG via samba wrote:
> A new update. Same behaviour with 4.6.16. Exact issue as Bug 1249.
4.6.6 is also EOL, it went EOL nearly two years ago. Bug 1249 refers to 
Samba 3 which is not only dead, it was also buried ;-)

Please upgrade to a supported Samba version, 4.10.x, 4.11.x or 4.12.x at 
this time (note that 4.13.0 is slated to be released in September, at 
which time 4.10.x will go EOL)

If your problem still exists in a supported version (higher is better), 
then a bug report can be opened and your problem can be looked into.

Rowland Penny

Samba team

Dear Rowland.

So sorry, I did not get the responses to this e-mail address, got them by
the purest change googling again.

I'm sorry to disagree with your approach:

1-. In my most recent updates you should have seen I am compiling Samba4
from source. Began with packaged distribution, but considering it might be
a bug, I decided to test myself. 4 different versions, same behaviour. This
means in my humble opinion it has nothing to do with the operating system
version or its "commercial" support.

2-. This is a basic feature; there is nothing strange in how the DC or the
Linux server are configured. So a basic issue with a basic feature
suggests, again in my humble opinion, there is a kind of misunderstanding
or regression bug here.

Will you please confirm it should works as described by man? I have look
into client.c, and the way cmd_mget and cmd_mput are programmed differs.

Many thanks. Best regards.

El lun., 24 ago. 2020 a las 14:48, LPC DPG (<lpcdpg at gmail.com>)
escribi?:
> A new update. Same behaviour with 4.6.16. Exact issue as Bug 1249.
>
> Many thanks. Kind regards.
>
> El lun., 24 ago. 2020 a las 12:23, LPC DPG (<lpcdpg at gmail.com>)
escribi?:
>
>> Dear folks.
>>
>> Was hoping it had to do with the release, but have also tested in
4.4.16
>> and the issue is also there. I am aware a RHEL/CEntOS based upon 6
>> distribution is not the most up to date version I should test this on,
as
>> it also limits how easy is compiling most recent versions of Samba, but
I
>> assume though this is not a tricky test, and should work as documented
in
>> both 4.4 and 4.2 versions.
>>
>> Looking forward to reading your remarks.
>>
>> Many thanks in advance. Best regards.
>>
>> El vie., 21 ago. 2020 a las 12:25, LPC DPG (<lpcdpg at
gmail.com>) escribi?:
>>
>>> Dear folks.
>>>
>>> I am using smbclient 4.2.10 version (the one packaged for OEL 6,
>>> samba4-client-4.2.10-15.el6.x86_64), and observing a weird
behaviour of the
>>> tool.
>>>
>>> I've got a Linux local directorio, say /tmp/eraseme, with a
couple of
>>> subdirectories in it, say a and b, each one containing a dummy
file, say
>>> a/AM.xls and b/AT.xls
>>>
>>> If I run:
>>> smbclient -d 30 -l /var/log/samba -m SMB3 -W "${d}" -U
"${u}" "${s}"
>>> "${p}"
>>> smb: \> lcd /tmp/eraseme
>>> smb: \> recurse
>>> smb: \> prompt
>>> smb: \> mask *M.xls
>>> smb: \> mput *
>>>
>>> it transfer both AM.xls an AT.xls files, which seems not to agree
what
>>> man page states:
>>>
>>> "       mask <mask>
>>>            This command allows the user to set up a mask which will
be
>>> used during recursive operation of the mget and mput commands.
>>>
>>>            The masks specified to the mget and mput commands act as
>>> filters for directories rather than files when recursion is toggled
ON.
>>>
>>>            The mask specified with the mask command is necessary to
>>> filter files within those directories. For example, if the mask
specified
>>> in an
>>>            mget command is "source*" and the mask
specified with the
>>> mask command is "*.c" and recursion is toggled ON, the
mget command will
>>> retrieve
>>>            all files matching "*.c" in all directories
below and
>>> including all directories matching "source*" in the
current working
>>> directory.
>>>
>>>            Note that the value for mask defaults to blank
(equivalent to
>>> "*") and remains so until the mask command is used to
change it. It retains
>>>            the most recently specified value indefinitely. To avoid
>>> unexpected results it would be wise to change the value of mask
back to "*"
>>> after
>>>            using the mget or mput commands."
>>>
>>> Nonetheless, if I do it the other way around,
>>>
>>> smbclient -d 30 -l /var/log/samba -m SMB3 -W "${d}" -U
"${u}" "${s}"
>>> "${p}"
>>> smb: \> lcd /tmp/eraseme
>>> smb: \> recurse
>>> smb: \> prompt
>>> smb: \> mask *M.xls
>>> smb: \> mget *
>>>
>>> , mget does seem to honour the referred description, downloading
only
>>> AM.xls file to Linux.
>>>
>>> I have been looking in Google, but have seen no reference to
similar
>>> problems. I do assume hence whether I am doing something wrong, or
>>> misinterpreting the manual, then I can't get it working.
>>>
>>> So I'd be really grateful if any of you who might have ever
faced
>>> something similar could share the experience, as I am really lost
with it.
>>>
>>> Thanks so much in advance. Best regards.
>>>
>>

On 24/08/2020 19:16, LPC DPG via samba wrote:
> Dear Rowland.
>
> So sorry, I did not get the responses to this e-mail address, got them by
> the purest change googling again.
>
> I'm sorry to disagree with your approach:
>
> 1-. In my most recent updates you should have seen I am compiling Samba4
> from source. Began with packaged distribution, but considering it might be
> a bug, I decided to test myself. 4 different versions, same behaviour. This
> means in my humble opinion it has nothing to do with the operating system
> version or its "commercial" support.
>
> 2-. This is a basic feature; there is nothing strange in how the DC or the
> Linux server are configured. So a basic issue with a basic feature
> suggests, again in my humble opinion, there is a kind of misunderstanding
> or regression bug here.
>
> Will you please confirm it should works as described by man? I have look
> into client.c, and the way cmd_mget and cmd_mput are programmed differs.
>
To ensure you get this, I have sent it direct to you and to the list ;-)

OEL 6 is very old and probably doesn't have the required versions of the 
dependencies needed to correctly compile the supported versions of Samba.

You do not say what versions of Samba you are compiling, but unless they 
are supported by Samba and still have the problem you are suffering 
from, you have very, very, little chance of getting it fixed.

Samba should work as the man pages suggest, but if it doesn't and it is 
a supported version, it should get fixed. Having said that, problems do 
get fixed on a regular basis, so a problem may get fixed in supported 
(at the time) versions, but would not get backported to unsupported 
versions unless a distro decided to do so. Once a problem is fixed in 
supported versions and not backported, it will not be fixed again in 
later versions (there would be no point) unless it is a regression.

You have a problem, but your distro is about to die and your version of 
Samba is equally old. The obvious way out of your problem is to upgrade 
Samba to a supported version, but this will probably entail upgrading 
your distro as well, something you seem loathe to do.

Sorry, if this isn't what you want to hear, but upgrading is the best 
way forward.

Rowland

Dear fellows.

Another piece of information. The issue reprduces on RHEL 7.7, Samba 4.9.1

[root at vnhprerhds01 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.7 (Maipo)
[root at vnhprerhds01 ~]# smbclient -V
Version 4.9.1

[root at vnhprerhds01 ~]# smbclient -W "${d}" -U "${u}"
"${s}" "${p}"
Try "help" to get a list of possible commands.
smb: \> !mkdir -p /tmp/borrame/a
smb: \> !mkdir -p /tmp/borrame/b
smb: \> !touch /tmp/borrame/a/AM.xls
smb: \> !touch /tmp/borrame/a/AT.xls
smb: \> !touch /tmp/borrame/b/BT.xls
smb: \> lcd /tmp/borrame
smb: \> cd borrar
smb: \borrar\> recurse
smb: \borrar\> prompt
smb: \borrar\> mask *M.xls
smb: \borrar\> mput *
putting file a/AT.xls as \borrar\a\AT.xls (0,0 kb/s) (average 0,0 kb/s)
putting file a/AM.xls as \borrar\a\AM.xls (0,0 kb/s) (average 0,0 kb/s)
putting file b/BT.xls as \borrar\b\BT.xls (0,0 kb/s) (average 0,0 kb/s)

I'll be trying next compiling 4.12.6 on OEL 6, which will take some time to
resolve dependencies, and if I am not able in a reasonable amount of time,
will do it on RHEL 7.7. It is really hard to believe this has not been
detected by noone else along the years. So I'm sure I'm doing something
wrong, seem so clumsy though to detect it myself.

Let you know about the progress. Best regards.


El lun., 24 ago. 2020 a las 20:16, LPC DPG (<lpcdpg at gmail.com>)
escribi?:
> Dear Rowland.
>
> So sorry, I did not get the responses to this e-mail address, got them by
> the purest change googling again.
>
> I'm sorry to disagree with your approach:
>
> 1-. In my most recent updates you should have seen I am compiling Samba4
> from source. Began with packaged distribution, but considering it might be
> a bug, I decided to test myself. 4 different versions, same behaviour. This
> means in my humble opinion it has nothing to do with the operating system
> version or its "commercial" support.
>
> 2-. This is a basic feature; there is nothing strange in how the DC or the
> Linux server are configured. So a basic issue with a basic feature
> suggests, again in my humble opinion, there is a kind of misunderstanding
> or regression bug here.
>
> Will you please confirm it should works as described by man? I have look
> into client.c, and the way cmd_mget and cmd_mput are programmed differs.
>
> Many thanks. Best regards.
>
> El lun., 24 ago. 2020 a las 14:48, LPC DPG (<lpcdpg at gmail.com>)
escribi?:
>
>> A new update. Same behaviour with 4.6.16. Exact issue as Bug 1249.
>>
>> Many thanks. Kind regards.
>>
>> El lun., 24 ago. 2020 a las 12:23, LPC DPG (<lpcdpg at
gmail.com>) escribi?:
>>
>>> Dear folks.
>>>
>>> Was hoping it had to do with the release, but have also tested in
4.4.16
>>> and the issue is also there. I am aware a RHEL/CEntOS based upon 6
>>> distribution is not the most up to date version I should test this
on, as
>>> it also limits how easy is compiling most recent versions of Samba,
but I
>>> assume though this is not a tricky test, and should work as
documented in
>>> both 4.4 and 4.2 versions.
>>>
>>> Looking forward to reading your remarks.
>>>
>>> Many thanks in advance. Best regards.
>>>
>>> El vie., 21 ago. 2020 a las 12:25, LPC DPG (<lpcdpg at
gmail.com>)
>>> escribi?:
>>>
>>>> Dear folks.
>>>>
>>>> I am using smbclient 4.2.10 version (the one packaged for OEL
6,
>>>> samba4-client-4.2.10-15.el6.x86_64), and observing a weird
behaviour of the
>>>> tool.
>>>>
>>>> I've got a Linux local directorio, say /tmp/eraseme, with a
couple of
>>>> subdirectories in it, say a and b, each one containing a dummy
file, say
>>>> a/AM.xls and b/AT.xls
>>>>
>>>> If I run:
>>>> smbclient -d 30 -l /var/log/samba -m SMB3 -W "${d}"
-U "${u}" "${s}"
>>>> "${p}"
>>>> smb: \> lcd /tmp/eraseme
>>>> smb: \> recurse
>>>> smb: \> prompt
>>>> smb: \> mask *M.xls
>>>> smb: \> mput *
>>>>
>>>> it transfer both AM.xls an AT.xls files, which seems not to
agree what
>>>> man page states:
>>>>
>>>> "       mask <mask>
>>>>            This command allows the user to set up a mask which
will be
>>>> used during recursive operation of the mget and mput commands.
>>>>
>>>>            The masks specified to the mget and mput commands
act as
>>>> filters for directories rather than files when recursion is
toggled ON.
>>>>
>>>>            The mask specified with the mask command is
necessary to
>>>> filter files within those directories. For example, if the mask
specified
>>>> in an
>>>>            mget command is "source*" and the mask
specified with the
>>>> mask command is "*.c" and recursion is toggled ON,
the mget command will
>>>> retrieve
>>>>            all files matching "*.c" in all
directories below and
>>>> including all directories matching "source*" in the
current working
>>>> directory.
>>>>
>>>>            Note that the value for mask defaults to blank
(equivalent
>>>> to "*") and remains so until the mask command is used
to change it. It
>>>> retains
>>>>            the most recently specified value indefinitely. To
avoid
>>>> unexpected results it would be wise to change the value of mask
back to "*"
>>>> after
>>>>            using the mget or mput commands."
>>>>
>>>> Nonetheless, if I do it the other way around,
>>>>
>>>> smbclient -d 30 -l /var/log/samba -m SMB3 -W "${d}"
-U "${u}" "${s}"
>>>> "${p}"
>>>> smb: \> lcd /tmp/eraseme
>>>> smb: \> recurse
>>>> smb: \> prompt
>>>> smb: \> mask *M.xls
>>>> smb: \> mget *
>>>>
>>>> , mget does seem to honour the referred description,
downloading only
>>>> AM.xls file to Linux.
>>>>
>>>> I have been looking in Google, but have seen no reference to
similar
>>>> problems. I do assume hence whether I am doing something wrong,
or
>>>> misinterpreting the manual, then I can't get it working.
>>>>
>>>> So I'd be really grateful if any of you who might have ever
faced
>>>> something similar could share the experience, as I am really
lost with it.
>>>>
>>>> Thanks so much in advance. Best regards.
>>>>
>>>