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).
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).
I'm sad about that. Thanks for the reply!
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.
Is this really the case that all mounting by label is deprecated?
Seems to be so for newly mounted filesystems
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.
Some discussions about the topic on github
Can we say ugly?
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.
Alles anzeigenHi,
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.
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.
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
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.
Thanks for all of your hard work by the way, your stuff is top-notch
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.
Guess Ive not followed it as closely as I should have.
You should spend more time on GH 
Personally, I would not change a filesystem because of a certain mount point. There should be better reasons.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
