Fresh install, Shared Folders + ZFS - Error 500.

  • Howdie gents.

    I have a fresh install of OMV7 with 1 ZFS pool imported, and I can't make any shares.


    The process to get here was exactly (I've done this a few dozen times over the years):


    • Install OMV
    • Update OMV
    • Install OMV-Extras
    • Install 'mc' (So I can visually see things)
    • Install Kernel Plugin
    • Install Proxmox 6.11 Kernel
    • Remove old kernels
    • Install ZFS plugin
    • Check for/apply Updates
    • GUI Import my (properly exported) ZFS pool
    • Click 'Discover'.
    • Literally nothing else - This is a fresh install.

    Now, as is the way ZFS works, I have a 'mypool' mountpoint on / already.


    Trying to make an SMB share, forces me to go back to the 'Shared Folders' page, where I can see all my filesystems, but even if I set relative path to /, It errors saying 'can't create /mypool/media/media' - I'm not, I'm trying to mount the share 'Media' which exists under my pool..... The other error is something along the lines of 'can't assign share to 'users' group' or something similar; that I'll have to check once I'm back at my server, as I don't have any sort of remote access setup yet (for obvious reasons).


    If I 'Apply Changes' (even though it looks like it failed) I can browse the SMB share, but it's read-only no matter what settings I change in the share.


    This worked so well for something like a decade, and now I'm hitting problems at literal initial setup :( what did I break?!

    • Official Post

    I assume you rebooted after installing the Proxmox kernel?

    Does the zfs filesystem show up in the Filesystems tab?

    Without an exact error (cut&paste from bell in the top right of OMV web interface), it is hard to say what is going wrong. It does seem like the zfs pool might be read only.

    omv 7.5.0-1 sandworm | 64 bit | 6.11 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.15 | compose 7.3.2 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    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;

    Yes, reboots were tried.

    Yes. They show in the filesystems tab.


    If I edit the auto filled relative path manually to add the share at "/"

    500 - Internal Server Error Failed to set file group to 'users' for '/MainTank/Media/': Unknown error


    If I let it do the default "media/" it tries to do (It shouldn't do this IMO, a selecting a folder shouldn't modify the drives, it should share whats there)

    500 - Internal Server Error Failed to create the directory '/MainTank/Media/Media/': Unknown error


    I'd say you're right about it being read only, but I've done nothing but the above steps (plus several reboots) so something in the import process is funky, if thats whats happened.

  • Master_Scythe IIRC, a fresh install allows you to connect to OMV via ssh as root and DHCP is used to acquire an IP. So you should have remote access from the outset. You ought to create a least one normal user account via "user management".


    Was the pool originally created in OMV? Use the CLI to check your pool rather than relying on the WebUI.


    Were export and import clean ? Use, for example, zpool history | egrep "export|import"

    Check pool status and datasets with zpool list -v and zfs list  Are dataset mount points as expected?

    Is it read only? Try to "touch" a file in the pool.

  • - Yes and no; I don't forward Port22 to the outside world, thats suicide.

    - No, the pool wasn't created in OMV, it was created with ZoL though and exported cleanly.
    - Export and import were clean.

    - Mountpoints are exactly as expected.

    - Pool is Healthy.

    - Filesystem is Read Only.


    So now the questions\bugs are:

    - WHY is it read only?

    - Why does that break sharing a folder?
    - Why does the 'Shared Folder' relative path default to trying to create a folder on my filesystem, and not "/"

  • Last question first. The action of creating a "shared folder" is either by using an existing "folder" or creating a new "folder" on the filesystem. The default is to create a new folder. In the case of ZFS, if the filesystem is a "dataset" then using "/" for the "relative path" means you are using the existing "dataset" mount path itself for the "shared folder" absolute path. In this case, OMV does not create a new folder, nor does it change/set permission of the "dataset" mount path. You may need to adjust these via the top section of the ACL function.


    Second Question. It follows if your filesystem is read-only then you cannot create a "shared folder" which attempts to create a new folder.


    First Question. I don't know how old your pool is, or it's been used in OMV before. Nor what the pool properties are. I don't have an immediate anwser to that. Please post the original zpool create statement used as taken from the zpool history.


    Edit: Should have said to check pool property "readonly" is set to "off".

  • So I've been studying the 'History' of this pool (luckily it's pretty new, so its short) and nowhere did I set it to readonly.

    It was though, and passing readonly=off has resolved this.

    So at the very least I've discovered 1 bug, perhaps 2.


    1. OMV errors out pointing a Shared Folder to "/" of a Read Only filesystem.


    This shouldn't happen, right?

    If my relative path is "/" then it shouldn't try to create a mountpoint ON the filesystem, it should be creating it on its boot drive, pointing AT the filesystem.


    Thats actually how I got access before starting this thread, I mapped the ZFS mount, FROM my boot drive, by selecting the boot drive as the filesystem in the 'Shared Folder' screen, instead of my ZFS filesystem.


    Can I suggest a tickbox for "Use Existing Mountpoint - Don't create a new one" ?

    I know OMV is designed for the prosumer, but the novices who do wander by might not know to change the autofilled "Video/" (My share name was Video) to "/".



    2. Something about the import made that dataset ReadOnly.


    Export and import history literally couldn't be cleaner:

    • 2024-12-16.16:44:08 export
    • 2024-12-21.22:49:35 zpool import -a

    And I was writing to that pool right up until export.

    • Official Post

    This shouldn't happen, right?

    If my relative path is "/" then it shouldn't try to create a mountpoint ON the filesystem, it should be creating it on its boot drive, pointing AT the filesystem.

    It isn't failing trying to create directory. It is failing trying to set the permissions to the permissions you select when creating a sharedfolder - https://github.com/openmediava…ed/rpc/sharemgmt.inc#L410


    I know OMV is designed for the prosumer, but the novices who do wander by might not know to change the autofilled "Video/" (My share name was Video) to "/".

    OMV is not designed for a prosumer. It is by far used by Linux noobs. That is why it is setting the permissions. If a noob create everything from the OMV web interface, the noob won't have this issue.

    Can I suggest a tickbox for "Use Existing Mountpoint - Don't create a new one" ?

    A sharedfolder is just a directory not a mountpint. So, the checkbox would have to be "Do not set permissions". I don't understand the need to share a read only filesystem but you would have to contribute the code or file an issue on the omv github.


    Something about the import made that dataset ReadOnly.

    Since you created the pool with a different version, all I can think is that your pool is using an unsupported option.

    omv 7.5.0-1 sandworm | 64 bit | 6.11 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.15 | compose 7.3.2 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    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!

  • Thanks for the reply :)

    Such a repsonsive dev, loving the work.

    It isn't failing trying to create directory. It is failing trying to set the permissions to the permissions you select when creating a sharedfolder - https://github.com/openmediava…ed/rpc/sharemgmt.inc#L410

    OK makes sense, so it's just the error thats misleading?

    • 500 - Internal Server Error Failed to create the directory '/MainTank/Media/Media/': Unknown error

    To me that looked like it was trying to create a directory, inside my dataset with the name 'Media'.


    As a Linux noob (but luckily familiar with BSD), I knew to set the Relative path to "/" which moved onto the

    "Failed to set file group" error I think you're referring to.


    My brain just clicked as to why we're seeing this differently:


    You're seeing this tool as a way to create a shared folder, for reference in other parts of OMV, right?

    If so, I think your view here is totally correct!


    I'm seeing this as a requirement to using SMB (from the GUI).

    I'm not trying to create anything, looking in MC I can see my mountpoint, I can see the dataset, I can explore it, I just want to share it.

    However doing so from SMB section of the GUI forces me to make a 'Shared Folder'.


    Perhaps the 'issue' is the SMB tool doesn't let me just choose an existing location?

    It sounds like it's because the 'Shared Foloder' step sets permissions, but what if someone wants to just.... share whats there, as is?


    Quote

    OMV is not designed for a prosumer. It is by far used by Linux noobs. That is why it is setting the permissions. If a noob create everything from the OMV web interface, the noob won't have this issue.

    I feel like I would classify there though.

    My linux experience stops at the Linux Mint Cinnamon Desktop.


    Moving a drive containing data from one system to another I'd still classify as a 'noob friendly' activity.

    Having somewhere to offload an array is more likely to be the 'pro' user.


    Quote

    I don't understand the need to share a read only filesystem but you would have to contribute the code or file an issue on the omv github


    Thats toally fair.

    In my case, I only own 1x BD-Rom these days, so I usually share it, rather than unscrewing it and moving it around.

    This isn't the usecase that popped up now but it's the prime reason I'd be sharing a Read Only Filesystem.


    Quote

    Since you created the pool with a different version, all I can think is that your pool is using an unsupported option.

    It is strange.... and that is logical, but doesn't check out.


    The POOL wasn't read only.

    The DATASET was.

    The dataset was created purely by inhereting from the pool.

    It also imported without the force flag, looking at history.


    I'm not sure even the force flag can import a pool thats created with unsupported features.


    This came up recently when the Windows and BSD versions of OpenZFS got RaidZ Expansion feature before Linux.

    I had to wait to move my ZFS drive from my Windows machine until the next point release.

    • Official Post

    It is not how I see it. I am telling you how OMV works. Creating a shared folder is not just to create the directory and set permissions. A shared folder is also an OMV database entry that OMV services can reference. It allows a shared folder to only have the path in one place.


    You are trying to do things outside of the OMV web interface and it does not match how OMV works. The web interface would have to have a way to determine if an existing directory was selected and an option in the permissions dropdown to not change anything. The former would be difficult.

    I feel like I would classify there though.

    My linux experience stops at the Linux Mint Cinnamon Desktop.


    Moving a drive containing data from one system to another I'd still classify as a 'noob friendly' activity.

    Having somewhere to offload an array is more likely to be the 'pro' user.

    That is well above many of the noobs trying to use an RPi to run OMV.

    omv 7.5.0-1 sandworm | 64 bit | 6.11 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.15 | compose 7.3.2 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    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!

  • Thats fair, sorry to assume.

    I expected how you saw it and how it worked would be aligned; but I guess how votdev sees it, is how it works.

    I can accept that and appreciate his work/vision. Thanks votdev!

    You are trying to do things outside of the OMV web interface and it does not match how OMV works.

    With the exception of installing MC so I could see my directories, at no time did I leave the web interface.


    - I moved a drive from my existing PC to my server.

    - I used the provided tool to import it.

    - I tried to share it over SMB.


    I'm honestly surprised this counts as 'well above' typical users needs.


    Is the only thing that makes it an "advanced" setup the fact that I moved a drive with data on it?

    I genuinely feel thats a very common request from new players, on places like reddit.


    That is well above many of the noobs trying to use an RPi to run OMV.


    Working literal decades in customer facing IT roles - I say with confidence and experience that even owning an SBC at all + learning how to image flash memory is a skill set wayyy above letting Nero burn a CD and rebooting a regular PC.

  • Yes, if the filesystem is ZFS and you're moving a pool between different operating systems.


    Wow, fair enough.

    It's certainly a different viewpoint for me. I'd never have put SBC users and people with spare hardware to offload already full drives to, as being 'more noob' than simply moving a drive in an X86_64 PC.

    But I'm well beyond arguing in life :) If those are the expectations, I can genuinely accept that.


    I've been asked to rewrite the r/homeserver wiki's OS section (I'm really enjoying that!) so knowing the expeced hardware, and expected drive layout of modern OMV will be helpful - I was familiar with 3.X prior.


    Cheers all! Merry Chistmas.

  • Master_Scythe


    The idea you should simply be able move a drive from a PC to a OMV NAS and access the data completely ignores the question of

    filesystem compatabilty.


    If the drive was originally formatted with a native Linux fs ( e.g. EXT4, XFS ..) then you can expect to mount the drive and access the data in OMV.


    If the drive was originally formatted with Windows NTFS, then at best you can expect to mount the drive and read the data in OMV. But the drive cannot be fully utilised without reformatting it with a native Linux fs.


    The case of OpenZFS is more complex. While in theory ZFS pools should be portable between difference OS, certain conditions apply. Even if a pool imports without error, differences in pool and/or dataset properties can cause problems, as can the permissions of the mount paths and the perms of the data held.


    Brief test of moving a OpenZFS pool from Win10 to OMV


    1. Create a zpool in win10 using latest release OpenZFSOnWindows-debug-2.2.6rc11.exe named wpool using two drives in a single mirror vdev.

    2. Create dataset wpool/data, wpool/music and load with sample data

    3. zpool export wpool

    4. detach disks from win10 VM and attach to OMV VM while both VMs stopped. (OMV VM loaded with zfs plugin and proxmox kernel 6.8, running zfs 2.2.6)

    5. Start OMV VM and "zpool import wpool" via WEbUI

    6. Check zpool status, zfs list, zfs properties and mount path permissions at CLI.


    The imported pool:



    Dir/File permissons:



    ZFS datasets and OMV shared folders


    The idea of a "shared folder" has always been central to the design of OMV. A "shared folder" is simply a named object within OMV's main config file which links to a directory path in your data. It is "shared folders" that link OMV services to given parts of your data.


    When you create a "shared folder" you either create a new folder and set its permission, or pick an existing one and if necessary adjust permissions using the separate ACL option. Deleting a "shared folder" does not delete the associated folder on the filesystem, nor the data it contains.


    Each ZFS dataset has its own mount path, an existing directory that can be picked when creating an associated "shared folder". As such it's permissions need adjusting. If the OMV default is to be used then this is: rwxrwsr-x with owner:group set to root:users.


    To use, for example, "/wpool/music" as the "absolute path" of an OMV "shared folder", the owner/group and std Linux perms must be adjusted as OMV uses "setguid" and every "User Account" is part of the "users" group. The owner/group and perms of individual files may also need adjusting.


    e.g from:


    root@omv7vm:~# ls -ld /wpool/music

    drwxr-xr-x 3 root root 13 Dec 25 11:26 /wpool/music


    to:

    root@omv7vm:~# ls -ld /wpool/music

    drwxrwsr-x 3 root users 13 Dec 25 11:26 /wpool/music

    root@omv7vm:~#


    NOTE: After making this type of change the pool may no longer be usable in windows 10.


    Finally, as to expected hardware etc in OMV7 you could do worse than start here: https://www.openmediavault.org/

    OMV7 will run on some of the popular low powered ARM SBC like the raspberry PI in addition to x86_64 hardware. OOTB OMV installs on a single device, including flashmedia. OMV is designed around OS and data separation. Your data can be held on one or more devices. Your data drives can be combined using a number of methods in OMV:


    mergerfs + (SnapRaid)

    LVM

    MD RAID

    BTRFS RAID profiles

    ZFS pools

    JBOD

  • If the drive was originally formatted with a native Linux fs ( e.g. EXT4, XFS ..) then you can expect to mount the drive and access the data in OMV.


    Because ZFS is one of the default filesystem's, including for Root/boot on Ubuntu, I think a lot of people wouldnt realise its not native. Being a kernel module and all.


    Good reading, the testing you did on windows, too.


    Ive used the OpenZFS tools for windows to recover data, but never created a pool there, so that was interesting.

  • Master_Scythe Ubuntu has blown hot & cold over ZFS use and its inclusion in their installer over last few releases. Debian uses their DKMS system with the required zfs-dkms package and dependencies to build the required modules. The use of the kernel plugin and installing a proxmox kernel avoids the need and possible glitches for such kernel module builds in OMV, but you can still stick to the "debian way" if you wish.


    If it wasn't already obvious, the OMV zfs plugin was a 3rd party project contribution that is now maintained thanks to ryecoaaron. It is not so fully integrated in OMV as BTRFS. For example, there is no snapshot scheduling function, no auto config of SMB shares to view/use snapshots as previous versions via "shadow copies" as there is with BTRFS. Scheduling scrubs would done via setting up timed tasks. The WebUI does not support the addition of log , cache or special devices. There's no support for ZFS send/receive or zfs native encryption. You'd have to resort to the CLI for these things. There is comprehensive notification of ZFS errors via the zfs event daemon, but zfs pool maintenance, such as replacing final drives, is strictly via the CLI. As newer functions are developed in zfs such as block cloning, raidz expansion, fast dedup and direct io, the OMV zfs plugin will fall further behind. But the OMV zfs plugin is sufficient to create a pool, dataset and zvols which may be all the average user needs.


    Yesterday was my 1st effort for OpenZFS in Windows ( an OS I hardly use). I've added a screen shot for the curious which shows the "napp-it webui" ( https://www.napp-it.org/downloads/windows_en.html )


  • I have spent 4 days on this issue.

    Hope it is similar

    I was trying to import existing zpool from old server.

    Importing worked but could not create filesystems or shares


    Solution:

    Put in new disk to the server and create new zpool basic


    After this all my pools showed up in web gui and were available for sharing.



    P.S. I spent 4 days on this but never found this post while searching forum or web (duckduckgo) but it was first post when I solved issue and clicked ZFS as tag to post solution

  • @b1adm What issue? You need to be more specific. If you imported a zfs pool from another server was it also "read only", or was there another problem? Did you simply not know that after import you had to click on the"discover" icon on the WEBUI ZFS POOLS tab?


    To save time, if you fail to find something on the forum, the simplest thing is to start a new thread.

    • New
    • Official Post

    after import you had to click on the"discover" icon on the WEBUI ZFS POOLS tab?

    Can you think of any reason the plugin should not automatically run the discover code after importing?

    omv 7.5.0-1 sandworm | 64 bit | 6.11 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.15 | compose 7.3.2 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    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!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!