getting SMART errors on removed drive?

  • Disable or delete the scheduled tests for the affected drives under Storage | S.M.A.R.T. | Scheduled Tests.

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


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.


  • I have no scheduled tests. ?(


    Edit: It looks like the decommissioned drive is still listed in /etc/smartd.conf


    smartd.conf says not to edit it because changes won't be saved - so where should I remove the offending entry?

  • How did you remove the failed drive?


    If you just unplugged the disk, that's not good enough. You have to delete it within the OMV GUI before physically removing it.

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


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.


  • I unmounted it and removed it. Didn't know I needed to "delete" it. Do I need to reinsert it and delete it to clear up this issue?


    If you "delete" a drive, does it delete any filesystems that are on the drive?

  • When you delete a drive you should be given a choice as to whether it is removed only or the filesystem is deleted losing the data.


    I would put it back in and then fully remove it in the GUI.

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


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.


  • I put it back in and if I select delete it warns that all filesystems will be erased.


    The solution here I found was to reinsert the drive, go to the SMART tab and disable SMART monitoring for this drive. Then when I unmount and remove the drive, the drive has been unlisted from smartd.conf, so I shouldn't get any more warnings on it.


    Marking this thread as resolved. Thanks for your help.

  • Actually I ran into this too. This is a valid issue, but it can be resolved.

    I had a single drive that was being monitored, I decided to remove the filesystem, shut down the PC and remove the drive and put it in another system.

    The next morning I got an email that smartd was still monitoring the drive, even though it no longer showed up under /storage/smart/devices because the drive was removed. There was still a reference to the drive in the file "/etc/smartd.conf".

    Putting the drive back like user jollyrogr mentioned, then removing it from monitoring is one way to do it.

    But if putting the drive back is not so easy, you can manually remove it from "/etc/smartd.conf".

    Note that it DOES say not to edit this file as it is autogenerated, or your changes will get lost. So I guess at some point if you edit monitored drives in the GUI will it autoremove the drive that is gone.

    • Official Post

    You need to remove the device from the database manually and redeploy the smartmontools settings.

    From the user's point of view, it makes sense that the monitoring is automatically removed when the drive is no longer present. But there are many things that make things quite complicated.


    The question is when should a device be automatically removed from monitoring? When a file system is removed? What if the user only wants to change the file system, e.g. EXT4 to BTRFS? Should a cron job check daily whether the device is still there and, if necessary, automatically remove the device from the database and redeploy the smartmontools?

Participate now!

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