rsync troubles in Opensuse 13.1

English Network/Internet
1

Hi,
I think a problem about rsync sits better here, rather than in the (more general) application forum. Sorry if it isn’t…

So, on to my problem:
I have a PC with OpenSuse, now updated to the latest 13.1 (previous there were 12.3, and earlier verions)
Installing was as a fresh install (after backing up all necessary files in the old 12.3).

Unfortunatelly, after setting up rcyncd with the old settings that worked OK in 12.3, in the new 13.1 things does NOT work 100%.

Usually I get to run (with cron) some rsync command from 2 other linux PCs). Now, in my new 13.1 system I get these verry annoying errors:
rsync: chgrp … failed: Operation not permitted (1)

Let’s be more specific:
rsync: chgrp “/backups/.etc–2013_11_17.tar.gz.4u31GL” (in backups_router) failed: Operation not permitted (1)
rsync: chgrp “/backups/.etc–2013_11_24.tar.gz.52XrGz” (in backups_router) failed: Operation not permitted (1)

If I simply remove those files and force rsync from the remote machine, the files does get copied OK, but still have the same annoying error about chgrp comes again:
rsync: chgrp “/backups” (in backups_router) failed: Operation not permitted (1)
backups/
backups/etc–2013_11_17.tar.gz
backups/etc–2013_11_24.tar.gz
rsync: chgrp “/backups/.etc–2013_11_17.tar.gz.Uh0iQN” (in backups_router) failed: Operation not permitted (1)
rsync: chgrp “/backups/.etc–2013_11_24.tar.gz.zfR7ol” (in backups_router) failed: Operation not permitted (1)

As you can see, first the files are copied (as normal, right ?) and then the error about chgrp appears (both in the remote machine console while executing rsync, and in my local machine’s rsyncd.log file)

When executing rsync at remote machine again I get these errors again:
rsync: chgrp “/backups/var–2013_11_24.tar.gz” (in backups_router) failed: Operation not permitted (1)
rsync: chgrp “/backups/var–2013_12_01.tar.gz” (in backups_router) failed: Operation not permitted (1)

So … what’s intriguing is that “temporary” file that reports this error (WHY is that .etc-2013_11_17.tar.gz.Uh0iQN" there, and what it has to do with anything ?!? (other than internal temporary file management of rsync))

After copying the files, in my local machine I see they have permissions 600 (while I expected them to be 644…)

The /etc/rsyncd configuration file is like this:
gid = users
read only = false
use chroot = true
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
###hosts allow = trusted.hosts
##slp refresh = 300
##use slp = false

[backups_router]
path = /CORNEL/SALVARI/ROUTER
comment = salvari ale backup-urilor de pe ROUTER
uid = cornel
gid = users
hosts allow = 192.168.0.1

Command executed at the remote machine is like this:
rsync -avz /backups cornel@192.168.0.199::backups_router

So … the files get the user/group settings OK, but for some reason permission gets to be 600 – which I don’t get were is set elsewhere.

If I execute rsync at my local end (with the proper parameters modified: rsync -avz 192.168.0.1:/backups /CORNEL/SALVARI_VIGRA/ROUTER ) things works smooth (and files are copied OK, with permisions 644 !!) – tested both after removing the files in order to force sync-ing , and after an already done sync (in which case the command reports that nothing is to be done – as expected)

So … does anyone clue me about where I should look in order to get rid of this annoying error about chgrp ?
I prefer to let the things as they are (and as they worked OK years before this update to Opensuse 13.1 !!! – older versions of rsync in previous Opensuse versions worked OK with the same settings ! )
Well if nothing can be done, I suppose I could change cron as to execute rsync from my local machine instead of executing it in the remote one, but still … I like to understand where’s my mistake (if any) and (if it’s the case) what changed in rsync to have this error now.

Thanx,
Cornel

P.S. Maybe it’s important: the path /CORNEL is from a sepparate partition (not directly into / – actually a symlink to the folder /lucru/CORNEL, where /lucru is the folder where that partition is mounted) … but that folder has permisions 775, and underneath it the other folders have the same permissions (775) so, I think this is not a problem here…)

2

corneld wrote:
> Hi,
> I think a problem about rsync sits better here, rather than in the (more
> general) application forum. Sorry if it isn’t…

That seems reasonable to me as well.

I can’t help much with your problem. It seems like it may be a
difference because of the rsync version. Have you googled and/or asked
on the rsync list about the problem? I suppose it might just be
something to do with the types of filesystems.

In general though, I think it’s considered better practice to pull the
backup onto the server rather than push it from the client, and I think
you say that configuration works, so I’d be inclined to just switch to
that arrangement. I do understand a curiosity to understand why, though!

Cheers, Dave

3

On 2013-12-04 13:06, corneld wrote:

> Usually I get to run (with cron) some rsync command from 2 other linux
> PCs). Now, in my new 13.1 system I get these verry annoying errors:
> rsync: chgrp … failed: Operation not permitted (1)

AppArmor?

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

4

Not anymore – thought about it myself before writing here, and uninstalled apparmor (all apps related to apparmor), but nothing changed… most likely the problem didn’t lied into anything related to apparmor

5

Check the permissions on the serverside
Check whether the UUID and GID’s are the same on both server and client !!!

6

On 2013-12-06 09:26, corneld wrote:

> Not anymore – thought about it myself before writing here, and
> uninstalled apparmor (all apps related to apparmor), but nothing
> changed… most likely the problem didn’t lied into anything related to
> apparmor

I would never uninstall apparmor. Simply look at the logs first.

Unistalling apparmor is akin to uninstalling the firewall, or the
antivirus in Windows.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

7

Thanx.

UID and GID were, of course, different between the “server” (machine that gets the sync-ed files) and the “client” (machine the pushes the sync-ing files).

That gave me a clue about options regarding preserving permissions in rsync.
And finally I got the culprit: the -a parameter in command !
As man rsync says: -a is equivalent with -rlptgoD ; the parameters -p -g and -o tries to preserve original UID and GID of the files after copying them to the destination (every file, when in the temporary state of copying, has permission 600).
Without these 3 parameters, I got rid of the error.

So the proper command would be, now as this:
rsync -rltDvz /backups cornel@192.168.0.199::backups_router

this copies OK the new files to server, and gives them ownership as instructed in the rsyncd.conf file on server, and permissions 644 – that’s perfectly OK with me now (despite they have different chown than at the client side).

Well… I suppose another solve for this would be to just add a new command on the script in the cron on client (to chown the files with UID and GID corresponding to those on server).
But I prefer the previous solve, since it’s more like I want to be.

Thanx all,