How do you handle the cryptic mountpoints

  • Hello,


    when accessing the shares via Samba, all is nicely ordered.

    But when accessing the filesystems via CLI, it is quite chaotic:


    In a previous version, the labels were used as mountpoints and I understand that that was ambigous.

    But would it not make sense to create a structure

    Code
    /filesystems/ 


    just like


    Code
    /sharedfolders/


    to avoid this chaos?


    Of course the question is how to name these drives. The UUID is only machinereadable, not humanreadable.

    I like the way docker does it. It creates human readable names (like "wild_weazle"). If they would be visible in both Gui and /filesystems/ this would work well, I think.


    Best regards,

    Hendrik

  • You can create symlinks, there's a plugin for that, so you can name them as you like.

    You can place them wherever you want and use those to manage files when using CLI/SCP.

    OMV BUILD - MY NAS KILLER - OMV 6.x + omvextrasorg (updated automatically every week)

    NAS Specs: Core i3-8300 - ASRock H370M-ITX/ac - 16GB RAM - Sandisk Ultra Flair 32GB (OMV), 256GB NVME SSD (Docker Apps), Several HDDs (Data) w/ SnapRAID - Fractal Design Node 304 - Be quiet! Pure Power 11 350W


    My all-in-one SnapRAID script!

  • to avoid this chaos?

    Use the symlinks plugin to make it more human readable, ;)

  • Thanks,


    that will help.

    What is still not nice about it is that there is no direct link from the Filesystems Tab in the GUI to the symlinks.


    Do you see what I mean?

    If I see that something is wrong in the Filesystems Tab, e.g. one drive is full or one is shown faulty. I still need to take that detour via the symlinks Plugin-Page.


    Don't you think it would be worth adding the human readable name to the filesystem Tab?


    How do commercial NAS do that?


    Best regards,

    Hendrik

    • Offizieller Beitrag

    How do commercial NAS do that?

    Most of them don't show you the path at all because you aren't using the system from the command line. OMV shows you the filesystem name when creating sharedfolders. The path is only needed when you are using command line (or docker which isn't native omv).

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

  • Do you see what I mean?

    I believe what you want is a deeper integration of the symlink plugin in the native sections of the GUI.

    Not sure if this is possible.

    OMV BUILD - MY NAS KILLER - OMV 6.x + omvextrasorg (updated automatically every week)

    NAS Specs: Core i3-8300 - ASRock H370M-ITX/ac - 16GB RAM - Sandisk Ultra Flair 32GB (OMV), 256GB NVME SSD (Docker Apps), Several HDDs (Data) w/ SnapRAID - Fractal Design Node 304 - Be quiet! Pure Power 11 350W


    My all-in-one SnapRAID script!

  • No, that is not really what I want.

    I think that no symlink is needed - creates unneccessary complexity.

    I suggest the following:

    When mounting a FS for the very first time, OMV proposes a human readable name to the user. Alternatively, the User can specify his own name.

    This name is stored in the config.xml. By this, the relation between UUID and this Name exists and from now on, this FS is always identifyable by this name.


    This name is also used for the mountpoint -and of course for every user-interaction. The UUID is only used internally and never shown to the User.


    Best regards,

    Hendrik

  • When mounting a FS for the very first time, OMV proposes a human readable name to the user.

    According to the dev, this is made on purpose to avoid conflicts.

    However, I agree is not user friendly, but thankfully there's a solution to this issue, as discussed.

    OMV BUILD - MY NAS KILLER - OMV 6.x + omvextrasorg (updated automatically every week)

    NAS Specs: Core i3-8300 - ASRock H370M-ITX/ac - 16GB RAM - Sandisk Ultra Flair 32GB (OMV), 256GB NVME SSD (Docker Apps), Several HDDs (Data) w/ SnapRAID - Fractal Design Node 304 - Be quiet! Pure Power 11 350W


    My all-in-one SnapRAID script!

    • Offizieller Beitrag

    That has already been tried and caused problems (not sure how long you have been around, but shared folders used to be mounted under /sharedfolders/folder_name ).


    The bind mounts created there caused issues, especially when docker came along. Thus why using absolute paths became the recommended usage outside of the webUI. Eventually users started figuring out symlinks were easy to create and easier than the long absolute paths. Then eventualy a symlink plugin was made to make them even easier to make.


    Thus where we are now.

  • Hello,


    but it is still a horrible user experience.

    I understand that OMV cannot work with sd[a,b,c,...], as they may change.

    So, OMV uses UUIDs internally. Fine.


    But then, to the user, when defining a sharefolder, it again shows sd[a,b,c...]


    I still do not see why we cannot give drives names the first time they show up (I would not even mind, if it would be Drive1, Drive2, ....) and Filesystems names on creation (by Default Filesystem1, Filesystem2, ... but overridable by the user). Note that for the mergerfs OMV is doing that already, see the screenshot.


    But then, it somhow already does what I want:


    See "DataPool1". It is probably legacy from OMV4? So, I do not understand why this was made worse. OMV6 now uses the (ever changing) devicename. Why is that a good idea? Using a devicename (DataPool1) when interacting with the user and ensuring that they are unique (i.e. not using the drive-labels, which could also be changed under bypassing the GUI) and using internally the UUID seems to me a safe bet.


    I know, I started discussing with the CLI User experience, but even in the GUI it is suboptimal.

    Don't get me wrong. I am grateful for this marvelous piece of software. This is meant in a constructive way.


    Regarding the /sharedfolders/: That is still existing on my system... Maybe because I upgraded from v4 to v5 to v6... But if these sharedfolder-mounts are problematic, why doesn't OMV now by default create the symlinks there?


    And at the same instance also at /filesystem/* for the Filesystems accoring to the naming that I outlined before.


    Apart from the work it would mean: Is there a technical reason against it?


    Greetings,

    Hendrik

    • Offizieller Beitrag

    dev-disk-by-label was deprecated because it caused problems for usb mounted hdd’s. With the growing number of RPi’s using OMV it was a necessary thing.


    It really is a blessing in disguise for all of us. Instead of /srv/dev-disk-by-label/disk1 you can now create a three-letter folder at the root level and with a symlink turn a very long uuid path into something like /sym/disk1. What’s not to like about that.


    If you must have a longer dev-disk-by-label you can change your Filesystem to BTRFS. I think it still uses the old mounting setup.

    • Offizieller Beitrag

    Apart from the work it would mean: Is there a technical reason against it?


    Greetings,

    Hendrik

    Mostly the issues it caused with USB enclosures, as mentioned. I was a bit miffed myself when disk-by-label went away (although I understood the reasoning)... however after spending a few minutes setting up symlinks.. I honestly am not sure I'd use labels anymore even if I could.


    I honestly think you're making a mountain out of a molehill, but that's just me. Doesn't kill the user experience at all. What kills the user experiences is the webUI being unusable because of a USB enclosure pretty much doing whatever it wants. That was happening with regular frequency, and going to UUID's was the only simple solution.

  • Are you asking for human readable drive names in the UI only?

    Like a symbolic name for a disk used throughout the UI instead of /dev/sd*?

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

  • I've enabled the sharedfolders on my OMV6, gets a bit confused sometimes when applying updates, but but overall, eventually works the way I used to in previous versions. I think that is what OP was originally complaining about.

    In subsequent posts in this thread he also mentions the inconsistent use of device ids in the UI and I see his point...

    I have 8 identical disks, same model number same size, etc. Only the content is different and label. Another thing that differs between restarts is the deviceID (dev/sd*)
    When trying to use any of the devices, the list that pops up to choose from gives no indication as too which disk is which, except on size and current "/dev/sd*" allocation (which changes) eg adding a sharedfolder, (ok right now, I only have 2 data with data so it is easy to tell which is what only by "used")


    and when I come to add a new filesystem or mount, the info to choose is is even more limited:

    one of these contains an old VMFS that I am happy to trash, another contains stuff I want to mount and access...

    Which is which?

  • But this is not a problem for shared folders. You can give names to your mounted file systems and these will be displayed.


    Unfortunately this is named comment, not label or name (USB-Disk1 is the comment for the file system)



    And this comment / name is displayed whan creating a shared folder.

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

  • But this is not a problem for shared folders. You can give names to your mounted file systems and these will be displayed.

    My first screenshot is from add sharedfolders, each of those disks contains shared folders but no indication of those is shown. The all have disk labels, but I have not added any "comments". Where is that?

  • Unfortunately this is named comment, not label or name (USB-Disk1 is the comment for the file system)

    Oh, I see it now, it's just an OMV internal label to tell the disks apart, got it

    just have to dig to find out which disk is which when I add the mount or FS, because that is still too little info in the UI

    I have to use something like lsblk -f to check manually

  • Maybe the serial number would help to identify disks, but what to do with raid volumes?

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

  • If you must have a longer dev-disk-by-label you can change your Filesystem to BTRFS. I think it still uses the old mounting setup.

    I do not think BTRFS is using mount by label. I switched to BTRFS way back in OMV5. I think that OMV5-21 was the rev. when we switched to mount by UUID. There is a kind of back door way to do it but with "Symlinks" add on (or doing it in CLI with ln -s) there is really no good reason for it.

    Linux Mint, EndeavourOS Arch Linux

    OMV6 NAS, bond0 LACP, Fractal Design Define R5 Case, Kodi "Omega", FreeBSD pfSense Plus firewall/router

Jetzt mitmachen!

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