LinuxQuestions.org - [SOLVED] rsync permission denied

- Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)

- - rsync permission denied (https://www.linuxquestions.org/questions/linux-server-73/rsync-permission-denied-906421/)

rsync permission denied

I've inherited two red hat 5 systems which are to be synchronized via an rsync script which runs as a cronjob. This is not happening and I've been tasked with finding out why.

The cronjob(currently commented out):

#15,45 * * * * /usr/bin/sudo /usr/local/lib/repl/netreg-repl.sh remotesystemhere
Script contents:

if [ "x$1" = "x" ]; then
echo "Usage: $0 desthost" 1>&2
exit 1;
fi
DEST=$1

$ECHO /usr/bin/rsync -aRve "ssh -i /home/repl/.ssh/id_rsa" \
--delete `/bin/cat /usr/local/etc/repl/filelist.txt` repl@"$DEST":/
Errors received:

sending incremental file list
/etc/
rsync: failed to set times on "/etc": Operation not permitted (1)
/etc/httpd/
rsync: failed to set times on "/etc/httpd": Operation not permitted (1)
/etc/httpd/MIKETEST
/etc/httpd/REPLTEST
/etc/httpd/ROOTTEST
/etc/httpd/conf.d/
rsync: failed to set times on "/etc/httpd/conf.d": Operation not permitted (1)
/etc/httpd/conf/
rsync: failed to set times on "/etc/httpd/conf": Operation not permitted (1)
rsync: mkstemp "/etc/httpd/.MIKETEST.wVy5bm" failed: Permission denied (13)
rsync: mkstemp "/etc/httpd/.REPLTEST.8no8zE" failed: Permission denied (13)
rsync: mkstemp "/etc/httpd/.ROOTTEST.rMzbYW" failed: Permission denied (13)

sent 725 bytes received 86 bytes 1622.00 bytes/sec
total size is 119555 speedup is 147.42
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6]
The user which runs the script is in sudoers:

repl ALL=(ALL) ALL
Defaults:repl !authenticate

I've tried adding -O to rsync, but it script still dies. I've also verified that the filesystem is local and not an NFS mount.

I am at my wits end and would appreciate any assistance!

Few questions for you:

1. You said that you are trying to sync data between two RHEL 5 servers. Then what does following means:

Quote:

I've also verified that the filesystem is local and not an NFS mount.

2. I am not exactly getting the script but what I can make out from it is you are trying to sync the data over ssh. Is that correct? If yes, then how file system can be local?

3. I would say it will be a good idea to configure the destination directory (directory in which you are trying to sync) with NFS and mount it on the source server. This will eliminate the user of ssh.

4. Your sudoers file says: repl ALL=(ALL) ALL. Shouldn't it be saying something like this

Code:

repl ALL=(ALL) NOPASSWD:

if repl is the user account that you are using for sudo. Ofcourse you can limit the user to execute particulars commands.

Request you to please make it a bit clear how the environment looks like and what exactly you are trying to do.

Greetings,

Thanks for the reply.

1. You said that you are trying to sync data between two RHEL 5 servers. Then what does following means:

What I mean is that the filesystem is local on both systems. None of the directories that I am working with reside on filesystems mounted via NFS. (or SMB/CIFS)

2. I am not exactly getting the script but what I can make out from it is you are trying to sync the data over ssh. Is that correct? If yes, then how file system can be local?

I am sorry for the confusion on this point. My use of the word local was only an attempt to indicate that the filesystems on the respective servers were not network mounts.

3. I would say it will be a good idea to configure the destination directory (directory in which you are trying to sync) with NFS and mount it on the source server. This will eliminate the user of ssh.

I am not able to do this unfortunately.

4. Your sudoers file says: repl ALL=(ALL) ALL. Shouldn't it be saying something like this

I tried that at one point and the errors persisted.

What I am trying to do is sync data from a set of directories on one system to another using an rsync script which is run via a cron job. Both systems in question are RHEL5.7 systems and are fully patched. These are systems which I inherited and I was told that the problem began shortly after the upgrade to 5.7.

Does this help to clarify my situation at all?

Thanks again for your assistance.

You're welcome. I tried to duplicate the issue and I think I am able to. Here are the errors that I got:

Code:

destination@sles11-server02:~/.ssh> rsync -a /home/destination/ source@192.168.10.1:/home/source/test

rsync: link_stat "/home/destination/.ssh/ssh" failed: No such file or directory (2)

rsync: failed to set times on "/home/source/test/.": Operation not permitted (1)

rsync: recv_generator: mkdir "/home/source/test/.fonts" failed: Permission denied (13)

*** Skipping any contents from this failed directory ***

rsync: recv_generator: mkdir "/home/source/test/.mozilla" failed: Permission denied (13)

*** Skipping any contents from this failed directory ***

rsync: recv_generator: mkdir "/home/source/test/.ssh" failed: Permission denied (13)

*** Skipping any contents from this failed directory ***

rsync: recv_generator: mkdir "/home/source/test/bin" failed: Permission denied (13)

*** Skipping any contents from this failed directory ***

rsync: mkstemp "/home/source/test/..bash_history.yokP9F" failed: Permission denied (13)

rsync: mkstemp "/home/source/test/..bashrc.4lo3Dn" failed: Permission denied (13)

rsync: mkstemp "/home/source/test/..emacs.2EOh84" failed: Permission denied (13)

rsync: mkstemp "/home/source/test/..inputrc.VcexCM" failed: Permission denied (13)

rsync: mkstemp "/home/source/test/..muttrc.JSTM6t" failed: Permission denied (13)

rsync: mkstemp "/home/source/test/..profile.Pj92Ab" failed: Permission denied (13)

rsync: mkstemp "/home/source/test/..vimrc.nkAj5S" failed: Permission denied (13)

rsync: mkstemp "/home/source/test/..xim.template.E8hAzA" failed: Permission denied (13)

rsync: mkstemp "/home/source/test/..xinitrc.template.O5wR3h" failed: Permission denied (13)

rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1040) [sender=3.0.4]

destination@sles11-server02:~/.ssh>

Here is my config that I used to test:

source: user account on my source server.
destination: user account on destination server. This account is setup with keybased authentication to login to source server using source user account.

Upload flow: From destination server to source server.

Reason of error: User source do not have sufficient rights to copy over the files received from the destination server to the location mentioned in the command.

Basically, user source do not have proper rights to /home/source/test on my source server. Fixing the rights resolved the issue.

I hope this helps.

Greetings,

That seems to match my results. What confuses me is that the user running the script has sudo access on both systems. When the script is invoked via cron, it is invoked with sudo. If the user is in sudoers and able to sudo should they not encounter permission errors?

Thanks again for your help.

You're welcome.

Well if you noticed I didnt even use sudo. The reason being when we mention the destionation path we are not using any command. It appears to me that sudo does not even come in picture when it comes to destination. sudo is there to execute commands with root priveleges. What if there are no commands just the path :-)

I hope that explains the issue.

Greetings,

Thanks for the explanation. I am baffled as to how this worked in the past when considering what you said. I've done further investigations and found two systems which use the same scripts, crontab, and user that seem to work without error. I compared permissions on /etc/httpd/ (for example) and can not find any differences between the working and non-working systems.

Thanks again for your help. I hope we can find a solution.

You're welcome. It might be possible that in your old script command is being passed on the destination (as I mentioned if you run a command with sudo it will not give you permission error but if it is just a path then yes it will).

As per the testing that I have done it revealed that it is a file system rights issue. Not sure, how it worked for you in past. There should be some difference in the past and current setup.

Does the receiving end have rsync running as root? If not, it wouldn't have permission to write in /etc (for good reason).

Greetings,

"As per the testing that I have done it revealed that it is a file system rights issue. Not sure, how it worked for you in past. There should be some difference in the past and current setup."

I am in agreement with that statement. I am stumped as I am unable to find any differences (except for sudo and rsync versions) between working and non working systems. Directory permissions, group memberships, user privs. are all the same (as far as I can tell) between the sets of systems. I am at a complete loss to explain this.

"Does the receiving end have rsync running as root? If not, it wouldn't have permission to write in /etc (for good reason)."

The receiving end does not run as root.

Thanks again for your assistance.

Hi all,

I added --rsync-path='/usr/bin/sudo /usr/bin/rsync' to my rsync script to ensure that rsync was being run with elevated privileges remotely. This corrected the issue. Thanks again to everyone for your assistance.