OMV now creating disk mounts by UUID rather than label?

blazini36 · 8. August 2021

Been running OMV for a while now and I've added a few disks through the web interface, nothing abnormal seeming there. I have to setup a separate 2nd snapraid array because the original array is getting a bit complicated. Snapraid allows this but the plugin interface in OMV does not so I have to set it up manually.

Anyway I went to check the disk mountpoints and everything added recently was mounted to /srv/dev-disk-by-uuid-##### rather than /dev/disk/by-label/XXX. I have 3 disks mountin like this now and it's kind of annoying to deal with when I'm used to looking at disks by label. I created the expected "/srv/dev-disk-by-label-" mountpooint directories manually and edited fstab manually to mount the drives to those mountpoint. OMV web interface wouldn't start after that so I had to restore the backup fstab file. probably had something to do with an OMV config file not matching

The symlinks for /dev/disk/by-label/XXX do exist for the new disks, I don't understand why it's using the UUID symlinks to mount these new disks..... any way I can fix these mount points?

gderf · 8. August 2021

See the changelog entry for openmediavault (5.5.20-1) near line 209. Disks that existed before the change will continue to mount by-label. Disks added after the change will mount by-UUID. I do not know of a way to revert the changed behavior.

https://github.com/openmediava…diavault/debian/changelog

andrzejls · 8. August 2021

Zitat von blazini36

Been running OMV for a while now and I've added a few disks through the web interface, nothing abnormal seeming there. I have to setup a separate 2nd snapraid array because the original array is getting a bit complicated. Snapraid allows this but the plugin interface in OMV does not so I have to set it up manually.

Anyway I went to check the disk mountpoints and everything added recently was mounted to /srv/dev-disk-by-uuid-##### rather than /dev/disk/by-label/XXX. I have 3 disks mountin like this now and it's kind of annoying to deal with when I'm used to looking at disks by label. I created the expected "/srv/dev-disk-by-label-" mountpooint directories manually and edited fstab manually to mount the drives to those mountpoint. OMV web interface wouldn't start after that so I had to restore the backup fstab file. probably had something to do with an OMV config file not matching

The symlinks for /dev/disk/by-label/XXX do exist for the new disks, I don't understand why it's using the UUID symlinks to mount these new disks..... any way I can fix these mount points?

I had same question week or so ago. The answer I got was that users that have no idea about Linux plug in and plug out usb dives without bothering to mount and then umount them. So like with everything else we have to bring all things to the lowest common denominator. And to answer your last questions, I got resounding NO.

andrzejls · 8. August 2021

Zitat von gderf

See the changelog entry for openmediavault (5.5.20-1) near line 209. Disks that existed before the change will continue to mount by-label. Disks added after the change will mount by-UUID. I do not know of a way to revert the changed behavior.

https://github.com/openmediava…diavault/debian/changelog

Line 209: "

openmediavault (5.5.20-1) stable; urgency=low

* Improved PHP and Python block device and filesystem implementation.

Re-add usage of /dev/disk/by-uuid device files for all filesystems

(except BTRFS) to workaround problems with JMicron based USB enclosures.

* Issue #894: Disabled cron jobs are still executed.

* Issue #896: Improve UDEV rule to fix issues with JMS567 SATA 6Gb/s

bridge based USB enclosures.

So why disks with BTRFS format get disk-by-uuid ? And all of this because issue with JMicron USB enclosures? Really!!!

blazini36 · 8. August 2021

Zitat von andrzejls

I had same question week or so ago. The answer I got was that users that have no idea about Linux plug in and plug out usb dives without bothering to mount and then umount them. So like with everything else we have to bring all things to the lowest common denominator. And to answer your last questions, I got resounding NO.

That doesn't seem like a very good reason unless I'm missing something. That is a good reason why OMV doesn't mount based on /dev/sda etc because that will always change unless forced by UUID.

The only way not properly unmounting a removeable drive is affected worse by using a label symlinked mountpoint vs a UUID symlinked mountpoint is if they had the same label I suppose. It would have been nice to have that as a configureable option because now my fstab is a mess.

umtauscher · 8. August 2021

Zitat von blazini36

It would have been nice to have that as a configureable option because now my fstab is a mess.

I agree 100%

I just installed OMV a few days ago and I was wondering, why the drives are mounted by uuid instead of the volume label, because I found this very unintuitive. Now I have an explanation at least, but I think it‘s a very bad design decision.

But its certain, that it confuses newbies the most.

BtW what noob would install OMV anyway?

ryecoaaron · 9. August 2021

Zitat von blazini36

my fstab is a mess

Everything OMV creates should be between the omv tags and is maintained by OMV. What difference does it make if it is a mess?

Zitat von umtauscher

why the drives are mounted by uuid instead of the volume label, because I found this very unintuitive.

Not sure why. It is very common and even the default for non-LVM partitions mounted by the Ubuntu installer. And since the goal of OMV is to do everything from the web interface, the mount point means little and the least problematic path should be used. It is much, much more likely that someone will put two drives in a system with the same label.

Zitat von umtauscher

But its certain, that it confuses newbies the most.

Why is a noob using the filesystem mount point? If docker is what you are referring to, they just need to look at the mount point in the Filesystems tab. There is nothing to really understand in this case.

Zitat von umtauscher

BtW what noob would install OMV anyway?

A large portion of the OMV user base are noobs.

blazini36 · 9. August 2021

Zitat von ryecoaaron

Everything OMV creates should be between the omv tags and is maintained by OMV. What difference does it make if it is a mess?

Because not every scenario is covered by OMV as I explained my reason for coming across the issue. I have to manually create and maintain a 2nd snapraid config because the plugin can't handle it. If I named a disk "DiskA" I know exactly what it's mountpoint is if it's done by label, it is /srv/dev-disk-by-label-DiskA and I can write that config rather easily. If I need to navigate that filesystem over SSH I know where I'm going, it starts /srv/dev-disk-by-label-DiskA/dirX. Now I have to keep note of the UUID of the disk just to navigate that........how is that "noob friendly"?

Zitat von ryecoaaron

Not sure why. It is very common and even the default for non-LVM partitions mounted by the Ubuntu installer. And since the goal of OMV is to do everything from the web interface, the mount point means little and the least problematic path should be used. It is much, much more likely that someone will put two drives in a system with the same label.

You pretty much just summed up the reason they should not have done this right there. The goal is to do everything from the web interface, and that's fine, but the reality is if you just look at posts on this forum is that'll pretty much never be the case. At any point when someone using Ubuntu learns about mounts and fstab they can (and will) adjust the mountpoint to be whatever they want and it will not be overwritten. That is not the case with OMV. I can't change the mountpoint but if it is done by label I gave the disk that label and it is familliar. The web UI has no real file browser, if I share a disk I can only ever navigate down through the clients filebrowser. If I need to get above the share I need to SSH in and navigate to the mountpoint. That gets inconvenient if I have 10 disks mounted by UUID

Zitat von ryecoaaron

Why is a noob using the filesystem mount point? If docker is what you are referring to, they just need to look at the mount point in the Filesystems tab. There is nothing to really understand in this case.
A large portion of the OMV user base are noobs.

That's kind of a silly thing to say, you can't actually be a noob for very long. Besides that everyone here who started using OMV was a noob at some point by definition.......we all made it through, and I doubt many people complained about disks being mounted by label rather than ID. This is the type of thing you would encounter if you bought a NAS box from some company and used their proprietary interface no one here did that, they built it, and they need to do maintenance on it that they wouldn't likely be doing on a Synology.

umtauscher · 9. August 2021

Maybe a compromise would be to have Options in the filesystems section to mount by dev, uuid or label. This way it could be different for internal an external drives.

It could default to uuid for the noobs.

votdev · 9. August 2021

Zitat von blazini36

The symlinks for /dev/disk/by-label/XXX do exist for the new disks, I don't understand why it's using the UUID symlinks to mount these new disks..... any way I can fix these mount points?

For the target OMV user the device file and the mount point of the file system is somewhat irrelevant. OMV does not use labels anymore because they made more troubles than they help.

Zitat von umtauscher

Maybe a compromise would be to have Options in the filesystems section to mount by dev, uuid or label. This way it could be different for internal an external drives.
It could default to uuid for the noobs.

I'm sorry, but this will never happen. This will break the design and concept of OMV which is to provide a simple UI with a minimal set of options and hide the user from everything what is done under the hood.

ryecoaaron · 9. August 2021

Zitat von blazini36

I have to manually create and maintain a 2nd snapraid config because the plugin can't handle it.

Feel free to submit a pull request. I don't have time to port much to OMV 6.x let alone this huge change that very few would use.

Zitat von blazini36

If I named a disk "DiskA" I know exactly what it's mountpoint is if it's done by label, it is /srv/dev-disk-by-label-DiskA and I can write that config rather easily. If I need to navigate that filesystem over SSH I know where I'm going, it starts /srv/dev-disk-by-label-DiskA/dirX. Now I have to keep note of the UUID of the disk just to navigate that

A one time symlink with the symlinks plugin can give you an even better path like /srv/diska/dirx. I do that myself. What wouldn't it solve?

Zitat von blazini36

how is that "noob friendly"?

You must be talking about a different kind of noob than I am. The noobs I have been supporting for over a decade are afraid to the use the command line.

Zitat von blazini36

but the reality is if you just look at posts on this forum is that'll pretty much never be the case.

There are plenty of power users who use the command line. Can't have a plugin for everything either.

Zitat von blazini36

At any point when someone using Ubuntu learns about mounts and fstab they can (and will) adjust the mountpoint to be whatever they want and it will not be overwritten.

The fact that OMV maintains mount point has never changed. ubuntu doesn't have any automatic mountpoint creation. So, the fact that ubuntu doesn't overwrite changes is not surprising.

Zitat von blazini36

The web UI has no real file browser, if I share a disk I can only ever navigate down through the clients filebrowser.

If you use the command line as much as it sounds, why not use mc? Writing a filebrowser plugin would be a project in itself.

Zitat von blazini36

That's kind of a silly thing to say, you can't actually be a noob for very long.

I beg to differ. I still get noob questions from people who have no desire to learn Linux because it isn't Windows.

Zitat von blazini36

I doubt many people complained about disks being mounted by label rather than ID.

But we did when people could mount their disks because they had the same label or people changed the label from the command line and their disk didn't mount.

And if you don't like anything else I said, just make your own entry in /etc/fstab, install the sharerootfs plugin, and create sharedfolders from a path without ever mounting anything in the web interface.

umtauscher · 10. August 2021

Zitat von votdev

I'm sorry, but this will never happen. This will break the design and concept of OMV which is to provide a simple UI with a minimal set of options and hide the user from everything what is done under the hood.

I am sorry, I think I have to find another NAS software…

KM0201 · 10. August 2021

Zitat von umtauscher

I am sorry, I think I have to find another NAS software…

Good luck.

You clearly do not understand the support nightmare this caused before... let alone giving users multiple options. People are making a huge issue of this, but the simple answer to this is exactly as ryecoaaron mentioned above, and that is symlinks. Even if you don't use the plugin it's easy... with the plugin it's ridiculously easy. At that point you can make your paths anything you want (everything on my server is mapped under "/NAS")

umtauscher · 10. August 2021

Zitat von KM0201

but the simple answer to this is exactly as ryecoaaron mentioned above, and that is symlinks. Even if you don't use the plugin it's easy... with the plugin it's ridiculously easy. At that point you can make your paths anything you want (everything on my server is mapped under "/NAS")

You lost me. Maybe I am too stupid but could you please explain what the Symlink plugin does and how it helps in any way?

To leave all the attitude behind I try to explain:

What I was doing, was to copy data from a local drive to one of the shares. Unfortunetely they are not mouted by label or device but by id. So I was constantly searching for the correspondig serial Number to find the right directory under /srv

The symlink plugin seems to create somesort of link, but how could I make use of it? Since OMV doesn't support any local file actions I fail to see what it could help.

KM0201 · 10. August 2021

Zitat von umtauscher

You lost me. Maybe I am too stupid but could you please explain what the Symlink plugin does and how it helps in any way?

To leave all the attitude behind I try to explain:
What I was doing, was to copy data from a local drive to one of the shares. Unfortunetely they are not mouted by label or device but by id. So I was constantly searching for the correspondig serial Number to find the right directory under /srv

The symlink plugin seems to create somesort of link, but how could I make use of it? Since OMV doesn't support any local file actions I fail to see what it could help.

Alles anzeigen

OK, not to sound like an asshole... You do know what a symlink is correct? No big deal if you don't, just to be clear... from the comment at the end it appears you don't. A symlink is basically what you described... a shortcut to another directory or file. If you create easy to remember symlinks, whatever has you so frustrated with UUID's, should be easy to overcome. Example:

The only place I really need my absolute paths, is in docker-compose... so what the absolute path is to a directory, is totally irrelevant to me unless it's a volume/folder I need to map to docker. I have directories under /srv/some-uuid/... So some examples

/srv/some-uuid/Movies

/srv/some-uuid/Music

/srv/some-uuid/TV

/srv/some-uuid/Torrents

and so forth. So I created a folder on my OS root partition called "NAS".. then I just symlinked those folders under my NAS folder.

So now, my docker-compose files, the volumes are much easier to deal with

/NAS/TV

/NAS/Movies

/NAS/Music

/NAS/Torrents

If I wanted to move something between folders, assuming they are both symlinked, it's just as easy with the mv command.

mv /NAS/Torrents/complete/Some_Artist /NAS/Music

Would move the directory "Some Artist" to my /NAS/Music folder.

I hope that makes sense... I can't really make it any simpler. I rarely use external drives, so maybe that's why I don't see the issue with this that others do.

umtauscher · 10. August 2021

thanks. Not what I would describe as „user friendly“.

Anyways thanks.

ryecoaaron · 11. August 2021

Zitat von umtauscher

thanks. Not what I would describe as „user friendly“.
Anyways thanks.

I guess I don't understand what you are trying to do. Are you using the command line or a client connected to OMV?

If you mount the filesystem in the web interface, create shared folder from that filesystem (shows label in selection dropdown), create samba share, and copy files to samba share.

If you are using command line, you mount from filesystems tab, look at mount point, add symlink in symlinks plugin from the mount you looked up to a path you can remember (example /srv/movies(. Then you when using the command line, you copy from the source location to /srv/movies/.

The first solution is how OMV has always been and user friendly for most. The latter might have an extra step but command line is not user friendly to most.

blazini36 · 11. August 2021

Zitat von ryecoaaron

Feel free to submit a pull request. I don't have time to port much to OMV 6.x let alone this huge change that very few would use.

Lol there's this notion that because you know a thing or 2 about Linux that you must be a programmer, I am not a programmer so I won't be submitting any pull requests. You missed my point though, you pretty much stated that everything should be done through the interface and I shouldn't be worried about mountpoints. And that's fine, I understand that but the point is that my use for snapraid is outside the scope of the interface. I'm not saying you need to fix the snapraid plugin, I'm explaining why I wave to diverge from the interface.

Zitat von ryecoaaron

A one time symlink with the symlinks plugin can give you an even better path like /srv/diska/dirx. I do that myself. What wouldn't it solve?

Well I've never tried that, I actually try not to diverge from the interface as you've suggested several times. It's hard to tell what's going to break OMV so I haven't experimented with that. It's obvious you're a dev and I thank you for the good work, but one thing I know about software guys is they get a bit overprotective of there design choices. This thing is an annoyance, it's not a dealbreaker. It doesn't really detract from OMV. I really just don't understand the reasoning for the design change itself that's the whole point of the post. Point is that with labels there was nothing to work around.

Zitat von ryecoaaron

You must be talking about a different kind of noob than I am. The noobs I have been supporting for over a decade are afraid to the use the command line.

There are plenty of power users who use the command line. Can't have a plugin for everything either.
The fact that OMV maintains mount point has never changed. ubuntu doesn't have any automatic mountpoint creation. So, the fact that ubuntu doesn't overwrite changes is not surprising.
If you use the command line as much as it sounds, why not use mc? Writing a filebrowser plugin would be a project in itself.

Again sort of missing the point. How many posts on here have someone with an issue and the response is that they should ssh in and do xyz? If someone is that scared of CLI they are probably using the wrong software, even Ubuntu can't keep people away from the terminal.

I don't use the CLI that often for OMV, I'm just not scared to do so when I have to. I've used Linux for many years which is the whole reason I built a NAS that runs Linux. The point about ubuntu is you brought it up because Ubuntu writes fstab with UUID's for disks that exist during install. OK but there's no management interface that is going to rewrite the change in fstab after you make it, it's not a 1:1 comparison.

I wasn't asking anyone to write a file browser plugin, again that wasn't the point. The point was simply that there is no file browser plugin so to get above a share I have to SSH in.........and that's completely fine. Point was when that is the case this new thing becomes an inconvenience. But yes I do use mc from time to time, glad you brought that up.............

See how easy it is to identify which disk I'm trying to access when it is "dev-disk-by-label-xyz"? That first weird one is my MergerFS mount.....no big deal, I know what it is. Now those "/dev-dev-by-uuid-1234" mounts I have no idea what those disks are. Now if all of these disks were by-uuid it would be really confusing. What's even more confusing is if it's a mergerFS disk without path preservation, it has all of the same directories as every other MergerFS disk so then ya have to run blkid to match the label to UUID to figure out what's what.

So OK, I concede that you can do stuff with more symlinks, but with labels you don't have to. So whyyyyyyyyyyyyy..........labels were so much betterrrrrrrrrrrrrrrrrr!

blazini36 · 11. August 2021

Zitat von votdev

For the target OMV user the device file and the mount point of the file system is somewhat irrelevant. OMV does not use labels anymore because they made more troubles than they help.

What is your target user?

What troubles did labels cause? I've been using OMV since 3 or 4 and never had an issue with labels. I've ran OMV on an rpi4, an Odroid N2, an Odroid H2, and currently a R5 3600 with like 15 disks.......no issues with labels

ryecoaaron · 11. August 2021

Zitat von blazini36

Well I've never tried that, I actually try not to diverge from the interface as you've suggested several times. It's hard to tell what's going to break OMV so I haven't experimented with that.

The symlinks plugin is a plugin in the web interface. It will not break OMV. I wrote it and use it myself.The worst thing a symlink will do is not work if the source is missing. I understand it is an extra step but that is the best I can do. Maybe my screen shots will help make sense. These four symlinks took about a min to make with the symlinks plugin and I use them when accessing the command since I don't remember which uuid is which.

Zitat von blazini36

What is your target user?

home and small office users.

Zitat von blazini36

What troubles did labels cause?

Mainly multi disk usb enclosures and multiple ntfs disks with the same label.

Jetzt mitmachen!