Do I need to be concerned about this S.M.A.R.T. message ....

  • 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 ... ?(

  • 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.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • 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.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • 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.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • 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).

  • 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.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • 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.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • 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).

  • 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.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!