How to mount HDD with OMV by label instead of UUID?

  • Hi,


    I want only dev-disk-by-label mount points in the /srv directory. OMV has mounted some HDDs by UUID.

    Unfortunately, OMV notes that no label was specified at mount time.

    The HDD will be labeled later, but after that OMV is always mounted it by UUID.

    How to delete this information from OMV (reset to default) or manually re-mount these HDDs by label?

    It does not seem like a good idea to manually write this in the fstab file. Unmount - mount did not help.

  • Since 5.5.20 drives are mounted by UUID and not label any more:

    https://www.openmediavault.org/?p=2866


    Not sure if it is possible to manually edit the mntent sections in /etc/openmediavault/config.xml and deploy the changes (which would rewrite fstab).

  • levi27

    Added the Label resolved
  • Since 5.5.20 drives are mounted by UUID and not label any more:

    https://www.openmediavault.org/?p=2866


    Not sure if it is possible to manually edit the mntent sections in /etc/openmediavault/config.xml and deploy the changes (which would rewrite fstab).

    Is this really the case that all mounting by label is deprecated? Hard to believe a global change like that was made just to accommodate some USB gear.

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

  • Seems to be so for newly mounted filesystems


    This is really disappointing.


    I wonder if it would have been possible to implement this as an option just for those who needed it, or at least have an easy way to revert to prior behavior for everyone else.

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

  • Can we say ugly?

    Gonna have to agree here. This seems to be a heavy handed fix for a small section of users, made to effect a much larger group of users.. I guess it isn't so much of a problem, as it is a major annoyance.


    That being said. I think to avoid this in the future, I'll be only using symlinks for my docker-compose/stacks now, just in case there is another change in the future. To me the only real advantage to using labels, was to make things easier with docker-compose.


    Right now, I've got all my AppData folders symlinked to /NAS/AppData and all my media and torrent folders mapped under /NAS/Media. Only real thing I had to do was chown the NAS folder to a regular user. This will keep my paths easy to remember. I was comfortable doing it via command line, but it was actually the first time Ive used the symiinks plugin, which made it point and click simple

  • I am affected by this change too even though I don't use said USB enclosures


    I have one SSD and two HDDs. The SSD is by id while the first HDD is by label. The new second HDD is by UUID no matter if I had a label or not. I wasted about an hour trying to figure out if I need to modify fstab or simply relabel/remount/reformat the HDD until I saw this


    Looks like I'll have to keep things in this uneven manner?

  • I am affected by this change too even though I don't use said USB enclosures


    I have one SSD and two HDDs. The SSD is by id while the first HDD is by label. The new second HDD is by UUID no matter if I had a label or not. I wasted about an hour trying to figure out if I need to modify fstab or simply relabel/remount/reformat the HDD until I saw this


    Looks like I'll have to keep things in this uneven manner?

    Is the new HDD formatted as btrfs or ext4? btrfs should still recognize labels.. ext4 is the issue. So if it is blank you can try reformatting it as btrfs and see if that helps.


    You could always go to symlinks, and then just make adjustments to your current docker containers.

  • That's not possible. OMV is deciding which device file is used.

  • Is the new HDD formatted as btrfs or ext4? btrfs should still recognize labels.. ext4 is the issue. So if it is blank you can try reformatting it as btrfs and see if that helps.


    You could always go to symlinks, and then just make adjustments to your current docker containers.

    Thanks! All of my HDDs, new and old, are formatted as EXT4. One of them was before 5.5.20 while the other was done after 5.5.20. This would mean that it is working as intended and therefore I should consider using symlinks like what you have already done.


    As for BTRFS, this seems more like a long term solution for me as I do indeed want a more robust filesystem like ZFS but simply do not have the hardware for it just yet. Is BTRFS stable enough even for production? Last time I heard it is not recommended (ZFS was promoted as the more stable solution instead)

  • Thanks! All of my HDDs, new and old, are formatted as EXT4. One of them was before 5.5.20 while the other was done after 5.5.20. This would mean that it is working as intended and therefore I should consider using symlinks like what you have already done.


    As for BTRFS, this seems more like a long term solution for me as I do indeed want a more robust filesystem like ZFS but simply do not have the hardware for it just yet. Is BTRFS stable enough even for production? Last time I heard it is not recommended (ZFS was promoted as the more stable solution instead)

    I'd agree with the long term solution. Bearing in mind that as far as I know, in omv 6 btrfs will be the only officially supported filesystem. I'm guessing Aaron will come up with a plugin to support ext4, etc. as he has others.


    My plan is to backup and go full btrfs at that time, but I will probably continue to use symlinks just in case something like this ever happens again. Plus, it also just makes it was way easier to remember my paths for docker, and it was dead nuts simple to set up.

  • I'd agree with the long term solution. Bearing in mind that as far as I know, in omv 6 btrfs will be the only officially supported filesystem. I'm guessing Aaron will come up with a plugin to support ext4, etc. as he has others.


    My plan is to backup and go full btrfs at that time, but I will probably continue to use symlinks just in case something like this ever happens again. Plus, it also just makes it was way easier to remember my paths for docker, and it was dead nuts simple to set up.

    Whoa, if this is true, is it a good idea for me to make the switch right now? The new HDD in question is going through badblocks to test that it works; I can always switch it to BTRFS instead of EXT4 once this is done and start testing if this works with whatever apps I am using

  • Bearing in mind that as far as I know, in omv 6 btrfs will be the only officially supported filesystem.

    That isn't going to happen in OMV 6. And I will definitely try to make a plugin to support ext4 if it does in OMV 7.

    omv 5.5.23 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • That isn't going to happen in OMV 6. And I will definitely try to make a plugin to support ext4 if it does in OMV 7.

    Hmm.. I seem to remember quite a fuss over that being in OMV 5, then votdev pushing it to OMV 6, so now it is OMV 7?


    Guess Ive not followed it as closely as I should have.


    The point still stands though, I had little doubt you'd try to make a plugin to accommodate all the users still using ext4 for their storage drives

  • One thing to keep in mind is that the change to mounting by UUID is not limited to newly added disks.


    From what I have seen, if your current disks are mounted by label and you unmount them, they will mount by UUID the next time.

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