This message is repeated about every 30 minutes in the S.M.A.R.T. log:
Should I be concerned about it?
If I should be concerned about it, could somebody please advise me what steps I should take to fix it ... 
Do I need to be concerned about this S.M.A.R.T. message ....
-
- OMV 5.x
- Taipan
-
Look in Storage | S.M.A.R.T. | Information | Extended Information for that device.
If you see non-zero Raw Values for ID#s 5, 197, and 198 I would suggest planning on replacing the disk ASAP.
-
This is what I see:
So, it looks like I need to replace that drive ...
Has it run out of spare sectors to re-allocate the faulty ones to?
Luckily, it is the second drive that I Rsynch to for a mirrored backup. The main drive is working fine ... so far.
Thanks for your advice ...
-
I have no idea how many spare sectors are available. I started looking into replacing a disk here when the reallocated sectors reached 8. I got a replacement disk in three days and by that time the count rose to more than 780. I was able to replace the disk without losing any data.
The longer you wait to replace the disk, the higher likelihood that it might completely fail.
-
So, it looks like I need to replace that drive ...
4648 reallocated sectors? That drive is close to being toast. It's good that it's your backup.
You might want to set up notifications, so you'll get E-mails regarding SMART stat changes and drive health. -
I replaced the deffective drive with a similar one (a Toshiba USB3 external drive), formatted it, mounted it and ran the Rsync command
rsync -av --delete --log-file=/var/log/rsync.log /srv/dev-disk-by-label-HDD1/ /srv/dev-disk-by-label-HDD2/
The new disk appears to be synced, as the used space is the same:
However, when I run the Rsync command again, manually, I get this error message:
Can anyone help with an explanation of what is going wrong now, please ...
-
Check your mountpoints. OMV 5 now mounts newly formatted disks by UUID instead of label unless the filesystem is btrfs.
-
Something appears to have gone wrong with the cron job. I would copy the command line into note pad or some other text editor, delete the Scheduled job and create a new one. Then copy the command line into the new Scheduled Job.
If you think the first sync completed, drop the section of the command with the log file. Go with simple until all is working well.
Is the platform an R-PI?
-
Check your mountpoints. OMV 5 now mounts newly formatted disks by UUID instead of label unless the filesystem is btrfs.
Could you please be more specific?
I am following the instructions on page 60 of the document "Getting_Started-OMV5.pdf" and it doesn't mention UUID.
What should the command line look like to use UUID?
I would copy the command line into note pad or some other text editor, delete the Scheduled job and create a new one. Then copy the command line into the new Scheduled Job.
If you think the first sync completed, drop the section of the command with the log file.I did exactly that and I still get a similar error message:
I have no idea what is going on here, and it seems odd that the Rsync worked fine once, but now throws an error?
Is the platform an R-PI?
Yes, with 2 x USB3 external Toshiba 2TB hard disk drives connected (separately powered).
-
"Something" must be changing the command before it runs. In the error message, don't understand where "rename" is coming from.
Have you tried SSH'ing in and running the command, from the command line? At least you could be assured that the copy took place.
What are you using as a boot drive and do you have backup?
-
What are you using as a boot drive and do you have backup?
I am using a top quality fully verified SD card as the boot drive and yes, I have a backup from the day before I replaced the faulty hard drive.
Using the backup (on another verified SD card), here is the result from SSH'ing in and running the same command with root permissions:
I get the same errors as I got from within OMV ...
What is "aquota.group" and aquota.user"? And why is the "Operation not permitted"?
Does the Rsync error (some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]) provide any clues?
-
You can not rename or delete the aquota.* files. Even the root user cannot do this because the immutable bit is set on them.
-
You can not rename or delete the aquota.* files. Even the root user cannot do this because the immutable bit is set on them.
So why has Rsync suddenly decided to rename the aquota.* files?
That is not a process that I am specifically initiating - I am just trying to execute the command rsync -av --delete --log-file=/var/log/rsync.log /srv/dev-disk-by-label-HDD1/ /srv/dev-disk-by-label-HDD2/.
Should I just start over and wipe HDD2, format, mount and run Rsync again to see if that clears the error messages?
-
So why has Rsync suddenly decided to rename the aquota.* files?
I don't have an answer to your question.
-
You can use masks to make excludes with --exclude-from, I have /$RECYCLE.BIN/ and /System Volume Information/
It looks like your rsync index is on the source drive your syncing. If so , it's very possible that rsync doesn't have the differentiability to spot suicide recursion (I've never tested this). So outside of removing the sticky bit, either let the errors happen or exclude the files. No biggie.
FWIW, I hazard to guess that rsync is trying to use rename because you've used --delete (after all rename is essentially the same as a delete after copy).
-
This is the permissions I have for those files:
Since we're talking about an R-PI try this line:
sudo rsync -av /srv/dev-disk-by-label-HDD1/ /srv/dev-disk-by-label-HDD2/
You're using OMV5, right?
I have an R-PI with two data drives. I'll set them up for a drive to drive and see what happens. -
OK, I tried
sudo rsync -av /srv/dev-disk-by-label-HDD1/ /srv/dev-disk-by-label-HDD2/ and the result is the same:
I am using version 5.5.23-1 of OMV, which I believe is the most current version.
The Linux kernal is version 5.4.83-v71, as shown above in the putty window.
-
-
You can attempt to change the permissions on the aquota.* files to whatever you want, as many times as you want, and as any user you want.
But until you unset the immutable bit as the root user you will get absolutely nowhere with this.
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!