Please forgive me if this has been asked and answered, but I have searched the forums and found no useful answer.
I have two identical FreeNAS server which I'm trying to mirror using rsync. The contents of the servers change frequently and at some point in time I would like to automate the mirroring function. But until I can figure out why some things work and other things don't, I will continue to do the rsync manually.
Here is the problem. I have an identical pool created on both machine A and machine B and within this pool I have created identical datasets. All datasets are then shared via SMB; again identically. Changes to the contents of the datasets only happens on machine A. On a periodic timetable, I have been trying to use rsync to copy the changes from machine A to machine B.
I have created a user admusr which owns the files and directories. In addition, I have created two groups; admgrp and usrgrp. admusr's primary group is admgrp and all other users belong to usrgrp. All members of admgrp have full access to all files and directories while usrgrp user have limited access to these same files and directories.
The command I'm have been using is trying to PUSH files from machine A to machine B as follows:
rsync -Aavr --partial --stats --progress --no-perms --delete --port 873 /mnt/tank/Clients/ admusr@192.168.1.201:/mnt/tank/Clients
This command appears to work correctly until the very end when it fails with a number of what appear to be permission errors. Here is the output:
root@HostA[~]# rsync -Aavr --partial --stats --progress --no-perms --delete --port 873 /mnt/tank/Clients/ admusr@192.168.1.201:/mnt/tank/Clients
admusr@192.168.1.201's password:
sending incremental file list
./
Grant.vbm
526,817 100% 29.47MB/s 0:00:00 (xfr#1, to-chk=32/34)
Grant2020-04-25T010024.vib
573,329,408 100% 104.19MB/s 0:00:05 (xfr#2, to-chk=1/34)
GrantD2020-03-19T010021.vbk
31,070,326,784 100% 104.20MB/s 0:04:44 (xfr#3, to-chk=0/34)
rsync: mkstemp "/mnt/tank/Clients/Grant/.Grant.vbm.tSj5O6" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/tank/Clients/Grant/.Grant2020-04-25T010024.vib.DuWZRh" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/tank/Clients/Grant/.GrantD2020-03-19T010021.vbk.FDrYHk" failed: Operation not permitted (1)
Number of files: 34 (reg: 33, dir: 1)
Number of created files: 2 (reg: 2)
Number of deleted files: 0
Number of regular files transferred: 3
Total file size: 94,461,364,705 bytes
Total transferred file size: 31,644,183,009 bytes
Literal data: 31,643,671,568 bytes
Matched data: 511,441 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 31,651,401,678
Total bytes received: 4,870
sent 31,651,401,678 bytes received 4,870 bytes 106,034,862.81 bytes/sec
total size is 94,461,364,705 speedup is 2.98
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1191) [sender=3.1.3]
I have tried this command while signed on as either admusr or root and under both circumstances, the command has failed exactly the same way. Finally, as last resort, I signed onto machine B as admusr and issued the exact same command, but this time as as "PULL" and it worked flawlessly! The command I used was as follows:
root@HostB[~]# rsync -Aavr --partial --stats --progress --no-perms --delete --port 873 admusr@192.168.1.200:/mnt/tank/Clients/ /mnt/tank/Clients
admusr@172.16.70.200's password:
receiving incremental file list
./
Fraser/
Frasier-old/
Grant/
Suffolk/
Suffolk/SuffolkD2020-03-26T020019.vbk
189,663,473,664 100% 76.09MB/s 0:39:37 (xfr#1, to-chk=14/102)
Veeam Recovery Media/
Wessex/
Number of files: 102 (reg: 95, dir: 7)
Number of created files: 1 (reg: 1)
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 578,715,813,583 bytes
Total transferred file size: 189,663,473,664 bytes
Literal data: 189,663,473,664 bytes
Matched data: 0 bytes
File list size: 3,889
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 363
Total bytes received: 189,709,782,472
sent 363 bytes received 189,709,782,472 bytes 79,526,213.72 bytes/sec
So what am I doing wrong on the "PUSH" scenario? What permissions have I overlooked and need to modify. The permissions for the directory I'm trying to mirror is exactly the same on both machines. As are the ACLs. Both permissions and ACLs have been propagated throughout the complete directory structure. The only difference that I can see is that the ZFS pool itself has different owner/group. On machine A tank is owned by root and wheel, while on machine B, tank is owned by admusr and usrgrp. Don't know how that happened, nor do I know how to change it!
drwxrwx---+ 8 admusr admgrp 8 Apr 21 05:54 Clients
admusr@HostB:/mnt/tank % getfacl Clients
# file: Clients
# owner: admusr
# group: admgrp
owner@:rwxpDdaARWcCos:fd-----:allow
group@:rwxpDdaARWcCos:fd-----:allow
everyone@:--------------:fd-----:allow
Thanks for any enlightenment anybody can offer. I would like to have this command work as a "PUSH" if at all possible because machine B is not always running.
If more information is needed, please let me know what further is required.
Greg ...
I have two identical FreeNAS server which I'm trying to mirror using rsync. The contents of the servers change frequently and at some point in time I would like to automate the mirroring function. But until I can figure out why some things work and other things don't, I will continue to do the rsync manually.
Here is the problem. I have an identical pool created on both machine A and machine B and within this pool I have created identical datasets. All datasets are then shared via SMB; again identically. Changes to the contents of the datasets only happens on machine A. On a periodic timetable, I have been trying to use rsync to copy the changes from machine A to machine B.
I have created a user admusr which owns the files and directories. In addition, I have created two groups; admgrp and usrgrp. admusr's primary group is admgrp and all other users belong to usrgrp. All members of admgrp have full access to all files and directories while usrgrp user have limited access to these same files and directories.
The command I'm have been using is trying to PUSH files from machine A to machine B as follows:
rsync -Aavr --partial --stats --progress --no-perms --delete --port 873 /mnt/tank/Clients/ admusr@192.168.1.201:/mnt/tank/Clients
This command appears to work correctly until the very end when it fails with a number of what appear to be permission errors. Here is the output:
root@HostA[~]# rsync -Aavr --partial --stats --progress --no-perms --delete --port 873 /mnt/tank/Clients/ admusr@192.168.1.201:/mnt/tank/Clients
admusr@192.168.1.201's password:
sending incremental file list
./
Grant.vbm
526,817 100% 29.47MB/s 0:00:00 (xfr#1, to-chk=32/34)
Grant2020-04-25T010024.vib
573,329,408 100% 104.19MB/s 0:00:05 (xfr#2, to-chk=1/34)
GrantD2020-03-19T010021.vbk
31,070,326,784 100% 104.20MB/s 0:04:44 (xfr#3, to-chk=0/34)
rsync: mkstemp "/mnt/tank/Clients/Grant/.Grant.vbm.tSj5O6" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/tank/Clients/Grant/.Grant2020-04-25T010024.vib.DuWZRh" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/tank/Clients/Grant/.GrantD2020-03-19T010021.vbk.FDrYHk" failed: Operation not permitted (1)
Number of files: 34 (reg: 33, dir: 1)
Number of created files: 2 (reg: 2)
Number of deleted files: 0
Number of regular files transferred: 3
Total file size: 94,461,364,705 bytes
Total transferred file size: 31,644,183,009 bytes
Literal data: 31,643,671,568 bytes
Matched data: 511,441 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 31,651,401,678
Total bytes received: 4,870
sent 31,651,401,678 bytes received 4,870 bytes 106,034,862.81 bytes/sec
total size is 94,461,364,705 speedup is 2.98
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1191) [sender=3.1.3]
I have tried this command while signed on as either admusr or root and under both circumstances, the command has failed exactly the same way. Finally, as last resort, I signed onto machine B as admusr and issued the exact same command, but this time as as "PULL" and it worked flawlessly! The command I used was as follows:
root@HostB[~]# rsync -Aavr --partial --stats --progress --no-perms --delete --port 873 admusr@192.168.1.200:/mnt/tank/Clients/ /mnt/tank/Clients
admusr@172.16.70.200's password:
receiving incremental file list
./
Fraser/
Frasier-old/
Grant/
Suffolk/
Suffolk/SuffolkD2020-03-26T020019.vbk
189,663,473,664 100% 76.09MB/s 0:39:37 (xfr#1, to-chk=14/102)
Veeam Recovery Media/
Wessex/
Number of files: 102 (reg: 95, dir: 7)
Number of created files: 1 (reg: 1)
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 578,715,813,583 bytes
Total transferred file size: 189,663,473,664 bytes
Literal data: 189,663,473,664 bytes
Matched data: 0 bytes
File list size: 3,889
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 363
Total bytes received: 189,709,782,472
sent 363 bytes received 189,709,782,472 bytes 79,526,213.72 bytes/sec
So what am I doing wrong on the "PUSH" scenario? What permissions have I overlooked and need to modify. The permissions for the directory I'm trying to mirror is exactly the same on both machines. As are the ACLs. Both permissions and ACLs have been propagated throughout the complete directory structure. The only difference that I can see is that the ZFS pool itself has different owner/group. On machine A tank is owned by root and wheel, while on machine B, tank is owned by admusr and usrgrp. Don't know how that happened, nor do I know how to change it!
drwxrwx---+ 8 admusr admgrp 8 Apr 21 05:54 Clients
admusr@HostB:/mnt/tank % getfacl Clients
# file: Clients
# owner: admusr
# group: admgrp
owner@:rwxpDdaARWcCos:fd-----:allow
group@:rwxpDdaARWcCos:fd-----:allow
everyone@:--------------:fd-----:allow
Thanks for any enlightenment anybody can offer. I would like to have this command work as a "PUSH" if at all possible because machine B is not always running.
If more information is needed, please let me know what further is required.
Greg ...
