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


Permission denied errors

2022-11-14 Thread Wes Render via rsync
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 user can list that folder without issue.


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


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

2021-06-04 Thread Knight, Dave via rsync
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
-- 
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


Permission Denied errors when trying to remove selinux contexts at destination

2014-03-13 Thread Bryan Pliatsios
Hi all,
rsync: rsync_xal_clear: lremovexattr(some/file/here,security.selinux) 
failed: Permission denied (13)
  I understand why these errors occur, but don't know the way to suppress or 
resolve these messages.
  Suggestions please. Pushing from v3.0.7 to a 3.0.6 server.

 Regards,
  Bryan-- 
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: rsync fails with Permission denied errors on random files over NFS

2009-06-10 Thread Thomas Damgaard
Bump.

I have still not found a solution for this. Do you have any ideas on
how to debug it?

Thanks.

Med venlig hilsen/Kind regards
Thomas Damgaard Nielsen
http://thomasdamgaard.dk



On Tue, Apr 28, 2009 at 2:35 PM, Thomas Damgaardthoma...@gmail.com wrote:
 Hi

 I use rsync for daily backups from a mailserver.

 Every day the mailserver pushes backup to the backupserver.
 Cron runs the command:
 rsync -q -zrlpt --specials --chmod=Du+rwx \
 --rsh 'ssh -F /root/ssh/config -i /root/ssh/private.key -o
 UserKnownHostsFile=/root/ssh/known_hosts'  \
 --files-from=/root/include \
 --exclude-from=/root/exclude \
 --link-dest=../previous \
 / backupu...@backupserver:backup/current

 The rsync command is run as the root user on the mailserver.

 /root/include contains the line:
 /data

 /root/exclude is empty at this moment.


 The problem is that almost every day, I get an e-mail from cron saying
 that rsync has failed.
 It gives errors like these:
 rsync: readlink
 /data/mail/virtual/xx-net.dk/martin/cur/1240839853.V11I228039M884633.mail:2,RS
 failed: Permission denied (13)
 rsync: readlink
 /data/mail/virtual/xx-net.dk/martin/cur/1240830282.V11I228031M150189.mail:2,S
 failed: Permission denied (13)
 rsync: readlink
 /data/mail/virtual/xx-net.dk/martin/cur/1240830490.V11I228036M432719.mail:2,S
 failed: Permission denied (13)

 I have checked that the files are ineed readable on the mailserver.
 Here is ls -l from one of them:
 -rw--- 1 mail mail 560383 2009-04-27 13:08
 /data/mail/virtual/xx-net.dk/martin/cur/1240830490.V11I228036M432719.mail:2,S


 The files that gives the error is appearently changing randomly. One
 day there can be one or two files with an error. Other times several
 hundred.
 I have seen it give errors on files in mail boxes that is currently
 unused, so it cannot be because the file is currently used by some
 other application (e.g. the imap server).

 I noticed that it is readlink that gives the error. I'm not sure why
 readlink is used in this case. This is a regular file and not a
 symlink.


 I hope you have some suggestions on how to debug this further.


 Details on the servers's file systems:

 Server backupserver:
 /data is mounted like this:
 nfs:/data/nfs/nfs0/data/xx/backup on /data type nfs
 (rw,timeo=60,intr,rsize=16384,wsize=16384,addr=78.xx.xx.xx)


 Server mailserver:
 /data is mounted like this:
 nfs:/data/nfs/nfs0/data/xx/mail on /data type nfs
 (rw,timeo=60,intr,rsize=16384,wsize=16384,addr=78.xx.xx.xx)


 Med venlig hilsen/Kind regards
 Thomas Damgaard Nielsen
 http://thomasdamgaard.dk

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


rsync fails with Permission denied errors on random files over NFS

2009-04-28 Thread Thomas Damgaard
Hi

I use rsync for daily backups from a mailserver.

Every day the mailserver pushes backup to the backupserver.
Cron runs the command:
rsync -q -zrlpt --specials --chmod=Du+rwx \
--rsh 'ssh -F /root/ssh/config -i /root/ssh/private.key -o
UserKnownHostsFile=/root/ssh/known_hosts'  \
--files-from=/root/include \
--exclude-from=/root/exclude \
--link-dest=../previous \
/ backupu...@backupserver:backup/current

The rsync command is run as the root user on the mailserver.

/root/include contains the line:
/data

/root/exclude is empty at this moment.


The problem is that almost every day, I get an e-mail from cron saying
that rsync has failed.
It gives errors like these:
rsync: readlink
/data/mail/virtual/xx-net.dk/martin/cur/1240839853.V11I228039M884633.mail:2,RS
failed: Permission denied (13)
rsync: readlink
/data/mail/virtual/xx-net.dk/martin/cur/1240830282.V11I228031M150189.mail:2,S
failed: Permission denied (13)
rsync: readlink
/data/mail/virtual/xx-net.dk/martin/cur/1240830490.V11I228036M432719.mail:2,S
failed: Permission denied (13)

I have checked that the files are ineed readable on the mailserver.
Here is ls -l from one of them:
-rw--- 1 mail mail 560383 2009-04-27 13:08
/data/mail/virtual/xx-net.dk/martin/cur/1240830490.V11I228036M432719.mail:2,S


The files that gives the error is appearently changing randomly. One
day there can be one or two files with an error. Other times several
hundred.
I have seen it give errors on files in mail boxes that is currently
unused, so it cannot be because the file is currently used by some
other application (e.g. the imap server).

I noticed that it is readlink that gives the error. I'm not sure why
readlink is used in this case. This is a regular file and not a
symlink.


I hope you have some suggestions on how to debug this further.


Details on the servers's file systems:

Server backupserver:
/data is mounted like this:
nfs:/data/nfs/nfs0/data/xx/backup on /data type nfs
(rw,timeo=60,intr,rsize=16384,wsize=16384,addr=78.xx.xx.xx)


Server mailserver:
/data is mounted like this:
nfs:/data/nfs/nfs0/data/xx/mail on /data type nfs
(rw,timeo=60,intr,rsize=16384,wsize=16384,addr=78.xx.xx.xx)


Med venlig hilsen/Kind regards
Thomas Damgaard Nielsen
http://thomasdamgaard.dk
-- 
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