But until you unset the immutable bit as the root user you will get absolutely nowhere with this.
I am sorry gderf , I don't understand what you are suggesting I do?
I have no idea what an "immutable bit" is, nor how to unset it. And, if I need to unset it, how did it get set in the first place?
Could you please be specific about what I need to do, as I am only a beginner ...
On first run, did it copy those files and now it can't overwrite them on subsequent runs?
Either way, should rysnc's index be identical on both source and destination... that seems error prone.
I am sorry gderf , I don't understand what you are suggesting I do?
I have no idea what an "immutable bit" is, nor how to unset it. And, if I need to unset it, how did it get set in the first place?
Could you please be specific about what I need to do, as I am only a beginner ...
Have you ever heard of a search engine?
On first run, did it copy those files and now it can't overwrite them on subsequent runs?
By "those files" do you mean the two aquota.* files?
In which case, you may be right (write?
) ... let me do some more research.
Have you ever heard of a search engine?
Yes, of course. But I was being lazy - sorry about that ...
I am not sure if I have done this correctly, but I have confirmed that the immutable bit is set, but now I am unable to unset it using chattr -i, as you can see here:
Obviously, I have done something wrong?
Does this help (from WinSCP):
When the file name is in WinSCP's right window, right mouse click the file, and click on properties.
___________________________________
My finding:
First, I updated my R-PI4 to the latest in update management..
I used the following command line:
rsync -av /srv/dev-disk-by-label-DATA1/ /srv/dev-disk-by-label-DATA2/
The first run, duplicated the drive. Since you had a problem on the second run, I ran it again. No issue.
I deleted a few files from the destination and ran it again. The exact folder and file structure was copied.
__________________________________
What you could try to do:
Before starting the following do a full update to be sure we're on the same page.
1. Install Midnight commander. How to install it and use it is -> here.
When you run it, use the command sudo mc.
Navigate to the destination drive and delete the files: quota.group and quota.user
(Running MC with sudo mc allowed me to do this.)
Run the command line again.
2. Consider using exclude statements as olduser suggested.
sudo rsync -av --exclude-from=/srv/dev-disk-by-label-HDD1/aquota.group --exclude-from=/srv/dev-disk-by-label-HDD1/aquota.user /srv/dev-disk-by-label-HDD1/ /srv/dev-disk-by-label-HDD2/
3. From here, I don't know what to tell you. I can't duplicate the problem or explain it so, the only thing I have to offer from here would be - Rebuild.
Operation not permitted while setting "flags" on HDD2? That could be what's locking those files.
Is anything referencing HDD2? Did HDD2 have shared folders in the past?
Thanks for all your help and advice so far crashtest - it is much appreciated ...
First, to answer your queries.
I tried using the exclude statements as suggested in 2. above, but then got this error about an "over-long filter":
I tried to use MC to delete the 2 aquota.* files on HDD2, but because they have the immutable bit set, I was denied permission.
I then tried to use sudo chattr -i /srv/dev-disk-by-label-HDD1/aquota.group to "unset" the immutable bit, but got the message "Operation not permitted while setting flags on"
So, it looks like I am stuck in a vicious circle ...
I gather that the 2 aquota.* files were created by the quota service at some stage?
I have never run the quota service and I checked (using sudo systemctl list-unit-files --type service --all) and the service is disabled:
HDD2 is a brand new disk drive and has never been used before nor had any shared folders on it before.
The questions I have are:
How do I find out what is stopping chattr from removing the immutable bit from these 2 aquota.* files on both HDD1 and HDD2?
How did the aquota files get created in the first place?
I don't think a re-build will help as the aquota.* files are stuck on both HDD1 and HDD2 and a rebuild will not remove them, unless I reformat HDD1 and HDD2? Given that there is over a TB of data on each drive, I would like to avoid starting from scratch ...
Useful topic for me, thanks all!
Do you have the same issue marcuspage ?
- I could, and did, delete the aquota.* files using sudo mc. I can delete those files from the source or the destination, using mc, with nothing special and no ill effects.
- The message "while setting flag" seems to be an indicator. Setting a flag should not be an indefinite operation.
Do you have users setup with home directories?
(Access Rights Management, Users, Settings Tab. If users do not have home dir's on the server, enable should be off.)
- To speculate, it seems that rsync running as root can't overwrite the files in the destination so it may be attempting to "rename".
**In searching the forum, I noticed this exact issue in two other recent posts.** There's an indication, in one case, that a dirty shutdown may have been involved. In the other case, the user successfully used the exclude statements.
______________________________________
An easy possibility is to reformat the destination drive and try again. (Maybe give it a unique label, this time, like HD2.)
This time around, use the command line with the exclude statements, from the beginning, so the problem files are not copied to the destination.
When I checked the quota service on my R-PI, it was dead.
This is worth a try:
(I see, above, that it's disable, but..)
sudo /etc/init.d/quota stop
(And)
sudo quotaoff --user --group /srv/dev-disk-by-label-HDD1
sudo quotaoff --user --group /srv/dev-disk-by-label-HDD2
__________________________________________________
**Edit**
Along other lines, a more abbreviated command line would be:
sudo rsync -av --exclude='aquota.group' --exclude='aquota.user' /srv/dev-disk-by-label-HDD1/ /srv/dev-disk-by-label-HDD2/
Alles anzeigenThis is worth a try:
(I see, above, that it's disable, but..)
sudo /etc/init.d/quota stop
(And)
sudo quotaoff --user --group /srv/dev-disk-by-label-HDD1sudo quotaoff --user --group /srv/dev-disk-by-label-HDD2
You cracked it crashtest ...
Once I executed those 3 commands, I was able to use sudo mc to delete all the aquota.* files that were on both drives.
No more confusing error messages ...
Thank you very much.
WOW... you should make crashtest some ascii art or something, he went way beyond the call of duty for all this.
WOW... you should make crashtest some ascii art or something, he went way beyond the call of duty for all this.
Yes, he (she?) certainly did persevere with this issue, and I am very grateful for crashtest 's knowledge and skills.
I managed to learn a lot more about OMV and Linux, too ... 
(I'm male BTW. In the pronoun soup, he, him or even "it", works fine. )
I try to work with beginner and intermediate users, in any case, but this one needed special attention.
IMHO: The rsync drive-to-drive mirror and recovery processes are the only data backup and restore that non-linux experts can perform easily and reliably. So,, running down a solution for this issue was important. This exception needs to be documented, in user doc's.
Since I couldn't duplicate this issue, it was necessary to "shotgun" it. I appreciate the efforts of all involved in suggesting and trying various approaches.
Thanks.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
