I'm trying to synch 2 directories and, using the example from the FAQ, my commands look like this: rsync -auqz directory1 remoteserver:/test rsync -auqz remoteserver:/directory1 /test If I change a directory's permissions and/or timestamp on the remote server the 1st rsync command changes it back to match the source. Files, however are unaffected and only get updated if newer. For example: (On remote server) drwxr-x--- 2 root sys 512 Jan 17 11:16 test/ (On source server) drwxrwxrwx 2 root other 178 Jan 17 10:36 test/ After the 1st command is run both directories look like the source server. If I were to switch these around it works fine. What I am doing wrong??? Doug
Doug: you're not doing anything wrong, from your description. You'll
find that if you change the mode on a file on the source that's already
identical to its counterpart on the destination, that change will be
propogated as well. Changing mode of a directory has no effect on the
modes of its contents, so there was nothing to do to the files in the dir.
That two-way sync you're doing is a bit dangerous, in most circumstances.
On the surface, it makes sense that the most-recently updated file is the
one you want. In most situations where someone wants that, it's possible
to have changes made on both sides, whereby he who saves last wins, and he
who saves first gets his changes discarded. Is that ok in your situation?
Tim Conway
tim.conway@philips.com
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
".\n" '
"There are some who call me.... Tim?"
"Doug Summers" <summersd@us.ibm.com>
Sent by: rsync-admin@lists.samba.org
01/17/2002 12:19 PM
To: rsync@lists.samba.org
cc: (bcc: Tim Conway/LMT/SC/PHILIPS)
Subject: Permissions Problems
Classification:
I'm trying to synch 2 directories and, using the example from the FAQ, my
commands look like this:
rsync -auqz directory1 remoteserver:/test
rsync -auqz remoteserver:/directory1 /test
If I change a directory's permissions and/or timestamp on the remote
server
the 1st rsync command changes it back to match the source. Files, however
are unaffected and only get updated if newer. For example:
(On remote server)
drwxr-x--- 2 root sys 512 Jan 17 11:16 test/
(On source server)
drwxrwxrwx 2 root other 178 Jan 17 10:36 test/
After the 1st command is run both directories look like the source server.
If I were to switch these around it works fine.
What I am doing wrong???
Doug
Here's my command copied from a shell script:\
rsync --verbose --progress --stats --compress --rsh=/usr/bin/ssh
--recursive --times --perms --links \
/home/* trt@xxxxxx.xxxxxxx.xxx:/remotebackups/
Here's some (a small part) of the output:
jk/.recently-used
253 100% 0.00kB/s 0:00:00
rsync: recv_generator: mkdir "jk/.secpanel/.runfiles": Permission
denied
(2)
stat jk/.secpanel/.runfiles : Permission denied
rsync: failed to open "jk/.viminfo", continuing : Permission denied
jk/.viminfo
4503 100% 0.00kB/s 0:00:00
rsync: recv_generator: mkdir "jk/Desktop/Trash": Permission denied (2)
stat jk/Desktop/Trash : Permission denied
jk/rsync.sh
161 100% 0.00kB/s 0:00:00
mkstemp jk/..bash_history.zb2Vlp failed: Permission denied
mkstemp jk/..fonts.cache-1.WRbevE failed: Permission denied
mkstemp jk/..recently-used.rleTG4 failed: Permission denied
mkstemp jk/..viminfo.IcFUcX failed: Permission denied
mkstemp jk/.rsync.sh.focqIP failed: Permission denied
rsync[17002] (sender) heap statistics:
arena: 1659224 (bytes from sbrk)
ordblks: 51 (chunks not in use)
smblks: 6
hblks: 1 (chunks from mmap)
hblkhd: 266240 (bytes from mmap)
usmblks: 0
fsmblks: 232
uordblks: 1509880 (bytes used)
fordblks: 149344 (bytes free)
keepcost: 132928 (bytes in releasable chunk)
The script is being run from the root account. My understanding is that
running as root will eliminate the permission errors, but apparently
that's not so.
On Mon, Dec 22, 2003 at 11:45:50AM -0800, John Davis wrote:> Here's my command copied from a shell script:\ > > rsync --verbose --progress --stats --compress --rsh=/usr/bin/ssh > --recursive --times --perms --links \ > /home/* trt@xxxxxx.xxxxxxx.xxx:/remotebackups/ > > Here's some (a small part) of the output: > jk/.recently-used > 253 100% 0.00kB/s 0:00:00 > rsync: recv_generator: mkdir "jk/.secpanel/.runfiles": Permission denied > (2) > stat jk/.secpanel/.runfiles : Permission denied > rsync: failed to open "jk/.viminfo", continuing : Permission denied > jk/.viminfo > 4503 100% 0.00kB/s 0:00:00 > rsync: recv_generator: mkdir "jk/Desktop/Trash": Permission denied (2) > stat jk/Desktop/Trash : Permission denied > jk/rsync.sh > 161 100% 0.00kB/s 0:00:00 > mkstemp jk/..bash_history.zb2Vlp failed: Permission denied > mkstemp jk/..fonts.cache-1.WRbevE failed: Permission denied > mkstemp jk/..recently-used.rleTG4 failed: Permission denied > mkstemp jk/..viminfo.IcFUcX failed: Permission denied > mkstemp jk/.rsync.sh.focqIP failed: Permission denied > rsync[17002] (sender) heap statistics: > arena: 1659224 (bytes from sbrk) > ordblks: 51 (chunks not in use) > smblks: 6 > hblks: 1 (chunks from mmap) > hblkhd: 266240 (bytes from mmap) > usmblks: 0 > fsmblks: 232 > uordblks: 1509880 (bytes used) > fordblks: 149344 (bytes free) > keepcost: 132928 (bytes in releasable chunk) > > The script is being run from the root account. My understanding is that > running as root will eliminate the permission errors, but apparently > that's not so.The permissions problems aren't local, they are on the remote server where you seem to be running as trt. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt
> Here's my command copied from a shell script:\ > > rsync --verbose --progress --stats --compress --rsh=/usr/bin/ssh > --recursive --times --perms --links \ > /home/* trt@xxxxxx.xxxxxxx.xxx:/remotebackups/It looks like you don't have the --delete in there (which you should have to keep identical copies on both sides, but I don't know your situation so take that with a grain of salt), so based on that, I would guess you *might* have a full disk on the machine that you are backing up to.> The script is being run from the root account. My understanding is that > running as root will eliminate the permission errors, but apparently > that's not so.You'll get the permission problems because a full disk will prevent you from adding anymore files onto it. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw@quantumlinux.com "You know what you get after putting 30 years into a company? You're looking at it." -Downsized CIO of a major insurance carrier.