Re: Permission denied errors

2022-11-15 Thread Paul Slootman via rsync
On Mon 14 Nov 2022, Wes Render via rsync wrote:

> Hello, I'm running an rsync like this:
> 
> rsync -avSHP --delete-after 
> --log-file=/opt/mirrorsync/centos_mirror/rsync-1.log 
> --exclude-from=/opt/mirrorsync/centos_mirror/excludelist.txt 
> rsync://centos.mirror.rafal.ca/CentOS/ /data/centos
> 
> I'm running as a user that has full permissions on /data/ and /data/centos, 
> but then I get the following errors, when the rsync runs the second time:
> 
> 2022/11/14 10:13:54 [68738] receiving file list
> 2022/11/14 10:13:56 [68738] rsync: opendir 
> "/7.9.2009/cloud/x86_64/openstack-train/repodata/.~tmp~" (in CentOS) failed: 
> Permission denied (13)
> 2022/11/14 10:13:56 [68738] rsync: opendir 
> "/7.9.2009/updates/x86_64/repodata/.~tmp~" (in CentOS) failed: Permission 
> denied (13)
> 2022/11/14 10:13:56 [68738] 198081 files to consider
> 2022/11/14 10:13:57 [68751] sent 62 bytes  received 15,071,081 bytes  
> 6,028,457.20 bytes/sec
> 2022/11/14 10:13:57 [68751] total size is 149,535,538,669  speedup is 9,921.98
> 2022/11/14 10:13:57 [68738] rsync error: some files/attrs were not 
> transferred (see previous errors) (code 23) at main.c(1819) [generator=3.2.3]
> 
> The strange thing is, if I login as this user, and do an: ls -la 
> /data/centos//7.9.2009/cloud/x86_64/openstack-train/repodata/.~tmp~

The error message is saying it can't open that file on the source;
testing access on your local (destination) system is irrelevant.

$ rsync 
'rsync://centos.mirror.rafal.ca/CentOS/7.9.2009/updates/x86_64/repodata/.~tmp~'
drwx--  4,096 2022/11/10 22:39:21 .~tmp~

$ rsync 
'rsync://centos.mirror.rafal.ca/CentOS/7.9.2009/updates/x86_64/repodata/.~tmp~/'
rsync: change_dir "/7.9.2009/updates/x86_64/repodata/.~tmp~" (in CentOS) 
failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 
23) at main.c(1819) [Receiver=3.2.3]


You might want to --exclude '.~tmp~'


Paul

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


Re: Permission denied errors with --append-verify run as non-root user

2021-06-04 Thread Kevin Korb via rsync
Short answer: Don't use --append[-verify]

If you aren't syncing files that aren't tagged with 'chattr +a' you
don't want --append.  --append-verify is essentially "I think --append
is a good idea to use on general files but rsync keeps corrupting
stuff!" but it still allows files to be out of sync since it ignores any
change to a file that doesn't make it a bigger file.  Essentially it is
for things like append only filesytem images and non-rotated log files.

All of that being said, rsync by default only transfers what is
different between the source and the target.  If a file has gotten
bigger only by adding stuff at the end rsync will figure that out and
transfer only the stuff that matters.  Any performance improvement you
are getting from --append-verify is either because it is ignoring file
changes that didn't result in a bigger file and because it causes file
updates to work like --inplace (which is what is causing your problem).

On 6/4/21 11:50 AM, Knight, Dave via rsync wrote:
> I noticed that my latest  "syncHome" script log scontained a number of
> unexpected "Permission denied" errors for some modified files.  The
> cause seems to be that those files were read-only at the target.  
> 
> The syncHome script is used to maintain a partial mirror of my home
> directory tree on another host.
> 
> Further investigation and some experiments led me to suspect the
> --append-verify functionality.  Specifically, those files were not
> rsync'd when the --append-verify rsync flag was specified but were
> properly rsync'd when --append-verify was NOT specified.  
> 
> Other rsync scripts that use --append-verify and are run as root seem
> not to exhibit this behavior.
> 
> FYI, I downloaded and built the "latest" version (rsync  version 3.2.3
>  protocol version 31) and with this version of rsync, the modified files
> are silently NOT rsync'd for both root and non-root users when
> --append-verify is specified.  When --append-verify is not specified,
> the updated files are rsync'd correctly.
> 
> That seems to me to be a serious bug, IMHO, because I "LIKE' to use
> --append-verify to ensure that large files are copied entirely without
> having to resync the entire file if there is an error.  If the
> --append-verify option */silently fails/* to rsync some updated files
> that */should/* be rsync'd, I cannot use --append-verify!
> 
> Please advise whether I am misunderstanding the purpose of, or misusing
> the  --append-verify flag or if this is a bug.   It is really easy to
> reproduce, BTW... 
> 
> Dave Knight 
> Radford, VA
> 
> 
> 

-- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
Kevin Korb  Phone:(407) 252-6853
Systems Administrator   Internet:
FutureQuest, Inc.   ke...@futurequest.net  (work)
Orlando, Floridak...@sanitarium.net (personal)
Web page:   https://sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html