This looks like the final phase of the problem arising from the
mounting issue I described earlier.

When I backup files using rsync from my work machine to my backup
machine, they all end up with owner (user) as root and group alan
(correctly), having started as alan:alan.

I have been faffing about all evening maling no progress at all.

This is one of the small folders used to test it.

rsync -rlptD --exclude-from=/home/alan/Scripts/exclude.txt --chown=alan:alan --progress /home/clnts_bkkpg/ /spare/churchill/clnts_bkkpg/

I have tried using -a instead of -rlptD even added -g and -o but that just slowed it down to zero movement.

I could live with it if I had to but it is irritating.

TIA

--
Linux Mint 21.1 kernel version 5.15.0-78-generic Cinnamon 5.6.8
AMD Phenom II x4 955 CPU 16Gb Dram 2TB Barracuda

On 2023-08-08, pinnerite wrote:
> This looks like the final phase of the problem arising from the
> mounting issue I described earlier.
>
> When I backup files using rsync from my work machine to my backup
> machine, they all end up with owner (user) as root and group alan
> (correctly), having started as alan:alan.

Your samba server's share options (and/or mounting options) are the
likely cause of these unwanted ownership changes.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On Tue, 8 Aug 2023 21:43:02 -0000 (UTC)
Dan Purgert <dan@djph.net> wrote:

> On 2023-08-08, pinnerite wrote:
> > This looks like the final phase of the problem arising from the
> > mounting issue I described earlier.
> >
> > When I backup files using rsync from my work machine to my backup
> > machine, they all end up with owner (user) as root and group alan
> > (correctly), having started as alan:alan.
>
> Your samba server's share options (and/or mounting options) are the
> likely cause of these unwanted ownership changes.
>

Thanks. Eventually I found that I had to run rsync as root.

Regards, Alan

--
Linux Mint 21.1 kernel version 5.15.0-78-generic Cinnamon 5.6.8

On 2023-08-09, pinnerite wrote:
> On Tue, 8 Aug 2023 21:43:02 -0000 (UTC)
> Dan Purgert <dan@djph.net> wrote:
>
>> On 2023-08-08, pinnerite wrote:
>> > This looks like the final phase of the problem arising from the
>> > mounting issue I described earlier.
>> >
>> > When I backup files using rsync from my work machine to my backup
>> > machine, they all end up with owner (user) as root and group alan
>> > (correctly), having started as alan:alan.
>>
>> Your samba server's share options (and/or mounting options) are the
>> likely cause of these unwanted ownership changes.
>>
>
> Thanks. Eventually I found that I had to run rsync as root.
>

Yeah, running as root will muck up ownership too ...

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 09/08/2023 11:10, Dan Purgert wrote:
> Yeah, running as root will muck up ownership too ...

Even with -a option?

David

On 2023-08-09, David Catterall wrote:
> On 09/08/2023 11:10, Dan Purgert wrote:
>> Yeah, running as root will muck up ownership too ...
>
> Even with -a option?

Yes, -a is the equivalent of -rlptgoD, which should preserve the
ownership details:

-r (recursive)
-l (copy symlinks)
-p (preserve permissions)
-t (preserve modification time)
-g (preserve group)
-o (preserve owner (superuser only))
-D (--devices and --specials)

Just so we're on the same page though, the original set of options was
only "-rlptD", so coupled with a CIFS share (and other things we don't
know, such as invoking the initial transfer with sudo), chances are
pretty high that the ownership (and group) information woud be changed.

Note that there are probably many cases where not using -o (-g) leaves
things perfectly "fine".

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

Just so it is clear, today completed a full backup of my work machine.
It took many hours. The result was perfect.

So this is an example of the mount statement and the rsync statememt.
I have five of each running from the script that is executed from a sudo:

mount -t cifs -o rw,noperm,user=alan,password=<my_password>,domain=ASANDCO,vers=1.0 //192.168.1.66/alan/ /spare/churchill/alan/

rsync -avz --exclude-from=/home/alan/Scripts/exclude.txt --chown=alan:alan --progress /home/alan/ /spare/churchill/alan/

Thr only niggle remaining is that I cannot get it to run from a desktop icon.
I'll return to that when I have time.
--
Linux Mint 21.1 kernel version 5.15.0-78-generic Cinnamon 5.6.8

On 2023-08-09, pinnerite wrote:
> Just so it is clear, today completed a full backup of my work machine.
> It took many hours. The result was perfect.
>
> So this is an example of the mount statement and the rsync statememt.
> I have five of each running from the script that is executed from a sudo:
>
> mount -t cifs -o
> rw,noperm,user=alan,password=<my_password>,domain=ASANDCO,vers=1.0
> //192.168.1.66/alan/ /spare/churchill/alan/
>
> rsync -avz --exclude-from=/home/alan/Scripts/exclude.txt
> --chown=alan:alan --progress /home/alan/
> /spare/churchill/alan/

huh, you shouldn't need the '--chown' switch here, with the '-a' flag
used. Furthermore, since you're sending it to a CIFS share, I'm
somewhat surprised it's retaining any of the unix ownership and mode
bits (normally, SMB/CIFS shares don't).

execution of the script itself as root would explain why "root" becomes
the owner though. Better to slap the 'sudo' into the command(s) that
need it in the script, rather than running the whole script with sudo.

>
> Thr only niggle remaining is that I cannot get it to run from a
> desktop icon.

Shell scripts are problematic at best when trying to run "from a desktop
icon".

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

Dan Purgert wrote:
> On 2023-08-09, pinnerite wrote:
>> Just so it is clear, today completed a full backup of my work machine.
>> It took many hours. The result was perfect.
>>
>> So this is an example of the mount statement and the rsync statememt.
>> I have five of each running from the script that is executed from a sudo:
>>
>> mount -t cifs -o
>> rw,noperm,user=alan,password=<my_password>,domain=ASANDCO,vers=1.0
>> //192.168.1.66/alan/ /spare/churchill/alan/
>>
>> rsync -avz --exclude-from=/home/alan/Scripts/exclude.txt
>> --chown=alan:alan --progress /home/alan/
>> /spare/churchill/alan/
>
> huh, you shouldn't need the '--chown' switch here, with the '-a' flag
> used. Furthermore, since you're sending it to a CIFS share, I'm
> somewhat surprised it's retaining any of the unix ownership and mode
> bits (normally, SMB/CIFS shares don't).
>
> execution of the script itself as root would explain why "root" becomes
> the owner though. Better to slap the 'sudo' into the command(s) that
> need it in the script, rather than running the whole script with sudo.

You need to run as root if you want to be able to set the ownership,
either to match the original files. Otherwise, all files will end up
owned by whichever user runs the command. Non-root users can't set the
owner/group of files - IIRC I think that's to prevent unprivileged users
from running arbitrary commands as root by just creating a script,
making it "setuid root" and running it (possibly some other
considerations as well).

>> Thr only niggle remaining is that I cannot get it to run from a
>> desktop icon.
>
> Shell scripts are problematic at best when trying to run "from a desktop
> icon".
>

On 2023-08-10, Mark Bourne wrote:
> Dan Purgert wrote:
>> On 2023-08-09, pinnerite wrote:
>>> Just so it is clear, today completed a full backup of my work machine.
>>> It took many hours. The result was perfect.
>>>
>>> So this is an example of the mount statement and the rsync statememt.
>>> I have five of each running from the script that is executed from a sudo:
>>>
>>> mount -t cifs -o
>>> rw,noperm,user=alan,password=<my_password>,domain=ASANDCO,vers=1.0
>>> //192.168.1.66/alan/ /spare/churchill/alan/
>>>
>>> rsync -avz --exclude-from=/home/alan/Scripts/exclude.txt
>>> --chown=alan:alan --progress /home/alan/
>>> /spare/churchill/alan/
>>
>> huh, you shouldn't need the '--chown' switch here, with the '-a' flag
>> used. Furthermore, since you're sending it to a CIFS share, I'm
>> somewhat surprised it's retaining any of the unix ownership and mode
>> bits (normally, SMB/CIFS shares don't).
>>
>> execution of the script itself as root would explain why "root" becomes
>> the owner though. Better to slap the 'sudo' into the command(s) that
>> need it in the script, rather than running the whole script with sudo.
>
> You need to run as root if you want to be able to set the ownership,
> either to match the original files. Otherwise, all files will end up

Sure, but if he's "alan" on both hosts, then we're right back to "you
don't need to run as root". (And ownership/permission capabilities
of smb/cifs anyway).

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On Fri, 11 Aug 2023 11:16:38 -0000 (UTC)
Dan Purgert <dan@djph.net> wrote:

> On 2023-08-10, Mark Bourne wrote:
> > Dan Purgert wrote:
> >> On 2023-08-09, pinnerite wrote:
> >>> Just so it is clear, today completed a full backup of my work machine.
> >>> It took many hours. The result was perfect.
> >>>
> >>> So this is an example of the mount statement and the rsync statememt.
> >>> I have five of each running from the script that is executed from a sudo:
> >>>
> >>> mount -t cifs -o
> >>> rw,noperm,user=alan,password=<my_password>,domain=ASANDCO,vers=1.0
> >>> //192.168.1.66/alan/ /spare/churchill/alan/
> >>>
> >>> rsync -avz --exclude-from=/home/alan/Scripts/exclude.txt
> >>> --chown=alan:alan --progress /home/alan/
> >>> /spare/churchill/alan/
> >>
> >> huh, you shouldn't need the '--chown' switch here, with the '-a' flag
> >> used. Furthermore, since you're sending it to a CIFS share, I'm
> >> somewhat surprised it's retaining any of the unix ownership and mode
> >> bits (normally, SMB/CIFS shares don't).
> >>
> >> execution of the script itself as root would explain why "root" becomes
> >> the owner though. Better to slap the 'sudo' into the command(s) that
> >> need it in the script, rather than running the whole script with sudo.
> >
> > You need to run as root if you want to be able to set the ownership,
> > either to match the original files. Otherwise, all files will end up
>
> Sure, but if he's "alan" on both hosts, then we're right back to "you
> don't need to run as root". (And ownership/permission capabilities
> of smb/cifs anyway).
>
I tried every combination but it only worked runnining as root.
HOWEVER, did you spot the chown=alan:alan among the rsync options?

--
Linux Mint 21.1 kernel version 5.15.0-78-generic Cinnamon 5.6.8

On 2023-08-12, pinnerite wrote:
> On Fri, 11 Aug 2023 11:16:38 -0000 (UTC)
> Dan Purgert <dan@djph.net> wrote:
>
>> On 2023-08-10, Mark Bourne wrote:
>> > Dan Purgert wrote:
>> >> On 2023-08-09, pinnerite wrote:
>> >>> Just so it is clear, today completed a full backup of my work machine.
>> >>> It took many hours. The result was perfect.
>> >>>
>> >>> So this is an example of the mount statement and the rsync statememt.
>> >>> I have five of each running from the script that is executed from a sudo:
>> >>>
>> >>> mount -t cifs -o
>> >>> rw,noperm,user=alan,password=<my_password>,domain=ASANDCO,vers=1.0
>> >>> //192.168.1.66/alan/ /spare/churchill/alan/
>> >>>
>> >>> rsync -avz --exclude-from=/home/alan/Scripts/exclude.txt
>> >>> --chown=alan:alan --progress /home/alan/
>> >>> /spare/churchill/alan/
>> >>
>> >> huh, you shouldn't need the '--chown' switch here, with the '-a' flag
>> >> used. Furthermore, since you're sending it to a CIFS share, I'm
>> >> somewhat surprised it's retaining any of the unix ownership and mode
>> >> bits (normally, SMB/CIFS shares don't).
>> >>
>> >> execution of the script itself as root would explain why "root" becomes
>> >> the owner though. Better to slap the 'sudo' into the command(s) that
>> >> need it in the script, rather than running the whole script with sudo.
>> >
>> > You need to run as root if you want to be able to set the ownership,
>> > either to match the original files. Otherwise, all files will end up
>>
>> Sure, but if he's "alan" on both hosts, then we're right back to "you
>> don't need to run as root". (And ownership/permission capabilities
>> of smb/cifs anyway).
>>
> I tried every combination but it only worked runnining as root.
> HOWEVER, did you spot the chown=alan:alan among the rsync options?

Which is the part I'm having trouble resolving on several levels, as

- '-a' sets owner/group (although you were using a subset of this
switch at one point, so..)
- CIFS/SMB shares don't do UNIX ownership anyway
- If you hadn't run as root, the calling user (alan) would've been used
in the first place.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860