HDD not showing mounted but is Referenced

    • OMV 4.x
    • kevke1990 wrote:

      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.
      No more contributions to this project until 'alternative facts' (AKA ignorance/stupidity) are gone
    • geaves wrote:

      kevke1990 wrote:

      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?
      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?


      crashtest wrote:

      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.


      tkaiser wrote:

      kevke1990 wrote:

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

      The post was edited 1 time, last by kevke1990: Extra information ().

    • kevke1990 wrote:

      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
      No more contributions to this project until 'alternative facts' (AKA ignorance/stupidity) are gone
    • Also sdc seems to be a ST3000DM001 running with a really outdated CC24 firmware (sdb uses at least CC29 while most recent one is CC4H). But this is another problem. First you need to solve the I/O error problem and when sdc is about to die then there's no need to think about firmware upgrades anyway :)
      No more contributions to this project until 'alternative facts' (AKA ignorance/stupidity) are gone
    • tkaiser wrote:

      tkaiser wrote:

      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, smartmontools.org

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

      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)
      No more contributions to this project until 'alternative facts' (AKA ignorance/stupidity) are gone
    • tkaiser wrote:

      kevke1990 wrote:

      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)
      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, 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?
      No more contributions to this project until 'alternative facts' (AKA ignorance/stupidity) are gone
    • tkaiser wrote:

      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!!
    • kevke1990 wrote:

      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).
      No more contributions to this project until 'alternative facts' (AKA ignorance/stupidity) are gone