HDD not showing mounted but is Referenced

  • Hi,


    I have a question about an issue i am encountering for a while now.
    When i reboot my OMV, my HDDDATA disk is "lost". When i search for disks after a few minutes the disk is showing up again.
    But when i check File Systems i see the following:



    Could you help me with the issue?


    Thanks!

    • Offizieller Beitrag

    I'm using MergerFS indeed. I'm not using SnapRaid.

    SnapRaid would make this easier to recover, I'll tag someone who has been using this longer than I have, does your fstab show the drives being used by MergerFS? and has the Union Filesystems in the GUI changed?

    • Offizieller Beitrag

    The disk highlighted (sde1) in the screen shot is packed. Did this problem of delayed disk recognition surface after the disk was filled to capacity?


    A few couple questions:
    What's the plaform? (x86 or SBC)
    What's the storage policy?

  • Could you help me with the issue?


    OMV is based on Linux and as such there are logs where almost everything that's needed to diagnose problems is written to (sometimes users need to enable more verbosity but most probably not in this case). In the OMV UI go to Diagnostics --> System Logs --> and check Syslog (the default log displayed).


    I would use the Download button to save latest syslog file locally, then use the Clear button next to it to empty the log file, then reboot and check again after few minutes what's written in syslog (looking for timeout and sharedfolder occurrences). Post syslog output here for others being able to help.

  • SnapRaid would make this easier to recover, I'll tag someone who has been using this longer than I have, does your fstab show the drives being used by MergerFS? and has the Union Filesystems in the GUI changed?

    In FSTAB i see all the drives including the mergerfs drive. The gui has changed. I see one N/A. that should be the HDDData drive. Is is easy (without loss of data) to configure SnapRaid?



    The disk highlighted (sde1) in the screen shot is packed. Did this problem of delayed disk recognition surface after the disk was filled to capacity?


    A few couple questions:
    What's the plaform? (x86 or SBC)
    What's the storage policy?

    No this problem surfaced earlier.


    It is a x86 platform. Bare metal configuration.
    JBOD is the storage policy i use.



    OMV is based on Linux and as such there are logs where almost everything that's needed to diagnose problems is written to (sometimes users need to enable more verbosity but most probably not in this case). In the OMV UI go to Diagnostics --> System Logs --> and check Syslog (the default log displayed).


    I would use the Download button to save latest syslog file locally, then use the Clear button next to it to empty the log file, then reboot and check again after few minutes what's written in syslog (looking for timeout and sharedfolder occurrences). Post syslog output here for others being able to help.

    I know OMV is based on Debian and i am not new to Linux but this is so strange. I did everything you said and I attached the syslog to this reply
    syslog.txt

    Einmal editiert, zuletzt von kevke1990 () aus folgendem Grund: Extra information

  • this is so strange

    That's tons of I/O errors with sdc. You need to fix this first before even thinking about high level stuff like filesystems, MergerFS, Snapraid or whatever else distracting topic has been brought up here. Solving such problems is always from bottom to top, that's why checking the logs is always first step.


    You should do an smartctl -x /dev/sdc and have a look at attribute 199. If the value is high then most probably it's a cable/connector problem, if not it's another problem most probably disk related. Please provide output from smartctl -q noserial -x /dev/sdc

  • You can also copy&paste the information from the OMV UI (delete the serial number then if you're concerned):

    I'm getting this information of the /dev/sdc disk:


    smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.19.0-0.bpo.4-amd64] (local build)
    Copyright (C) 2002-16, Bruce Allen, Christian Franke, http://www.smartmontools.org


    Short INQUIRY response, skip product id
    A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

  • A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options

    That's bad news but you should do what the message is suggesting: smartctl -q noserial -T permissive -x /dev/sdc (if it's not working add '-T permissive' multiple times until smartctl succeeds and prints disk health information)

  • That's bad news but you should do what the message is suggesting: smartctl -q noserial -T permissive -x /dev/sdc (if it's not working add '-T permissive' multiple times until smartctl succeeds and prints disk health information)

    After multiple times I keep getting the same information:


    smartctl -q noserial -T permissive -x /dev/sdc
    smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.19.0-0.bpo.4-amd64] (local build)
    Copyright (C) 2002-16, Bruce Allen, Christian Franke, http://www.smartmontools.org


    Short INQUIRY response, skip product id
    Read Cache is: Unavailable
    Writeback Cache is: Unavailable


    === START OF READ SMART DATA SECTION ===
    SMART Health Status: OK
    Current Drive Temperature: 0 C
    Drive Trip Temperature: 0 C


    Read defect list: asked for grown list but didn't get it
    Error Counter logging not supported


    Device does not support Self Test logging
    Device does not support Background scan results logging

  • That's bad news. A simple web search for 'smartctl ST3000DM001' shows you how SMART information should look like. Does the same happen with the other ST3000DM001 (/dev/sdb)?


    I guess those disks are all connected to one of the 6 SATA ports your mainboard provides?

    I tried it with the other disk. There is no problem with that one.
    You are wright. They are all connected to the mainboard. I already tried different ports. I also changed the cable. I guess I need to replace the SATA cable.


    Thanks for your very good troubleshooting and quick response every time!!

  • I guess I need to replace the SATA cable

    Maybe it's the disk that's causing troubles. Anyway: if you replaced the cable and can query the disk for SMART data write the 199 value down, then do a hdparm -t /dev/sdc (read test) and then compare value of attribute 199 again. If the value has increased you still have an interface problem.


    And in case the disk comes back you might consider upgrading the firmware to CC4H (can be done from Linux with SeaChestLite).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!