Which is the right mountpoint folder now (5.5.3) ?

  • What is the correct mountpoint directory naming for filesystems in OMV5?


    I updated from OMV4 and an existing disk 'BACKUP' came over as /srv/dev-disk-by-label-BACKUP and a newly-added disk 'DATARAID' mounted at /srv/dev-disk-by-label-DATARAID. Okay, all consistent.

    Since the last update (5.5.3-1), the RAID array has moved to /srv/dev-disk-by-label/DATARAID although /srv/dev-disk-by-label-DATARAID still exists, empty. I'm confused! :S Having filesystems mounted in two different places really is not helpful. I also had some complaints today from rsync on OMV, ERROR: Source storage device not mounted at </srv/dev-disk-by-label-DATARAID/>! - so presumably parts of the system are just as confused by the change of mountpoint as I am!


    Which is the correct mountpoint directory naming and how do I correct whichever of the two above is wrong? Can I safely remove whichever directory is the incorrect mountpoint format?


    Thanks!

    • Offizieller Beitrag

    That is the correct location. I would guess there is something wrong with your raid array and the filesystem didn't mount.

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Sorry, ryecoaaron, which one is the correct location? I have two going on... should it be dev-disk-by-label-FSLABEL or dev-disk-by-label/FSLABEL?


    fstab has the same confusion over what the directory structure is:

    /dev/disk/by-label/DATARAID /srv/dev-disk-by-label/DATARAID ext4 ...

    /dev/disk/by-label/BACKUP /srv/dev-disk-by-label-BACKUP ext4 ...


    The system says the RAID array is fine (and so it ought to be, on two brand new disks!), but it is two passed-through disks on a proxmox host, so I guess there's potential that there was a temporary glitch somewhere. Nothing has rebooted recently, so there's no reason any FS would have been remounted, which makes the change in one mount point but not the other all the more puzzling.

    • Offizieller Beitrag

    Hmmm.... I guess I haven't mounted a new drive in a while. The mountpoint shouldn't be three levels deep. What is the output of: omv-showkey mntent

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Looks strange; for shares on the same filesystem, we have both directory formats, -fslabel and third level /fslabel.

  • Right. I corrected config.xml so that everything is referring to /srv/dev-disk-by-label-FSLABEL and not any third level directory, ran "omv-salt deploy run fstab", and "... mdadm" for good measure, and rebooted the OMV server.


    The mount points now look correct; the array has moved from md127 to md0 for no particular reason, but that's up to linux.


    I've manually removed the third-level directory DATARAID and another mountpoint leftover from a filesystem that the RAID replaced and isn't mentioned anywhere in the config, that OMV hadn't cleaned up. Also found a load of the old OMV4 /sharedfolders were still there, so cleaned those up too (I don't have the sharedfolders option on in OMV5).


    Hopefully that's the last of this weirdness!

Jetzt mitmachen!

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