Beiträge von molnart

    i did a fresh reinstall, upgraded to arrakis, installed a bunch of plugins and the Failed to read file '/tmp/bgstatusybb9l8' (size=0). error reappeared.


    the issue started with this plugin installation (pasted only the errored parts):






    I suspect it's virtualbox causing the issue in my case, as it was plugin i installed in the previous run as well.

    i am also having similar error, with stuck "configuration has been changed" banner. omv-aptclean and removing dirtymodules.json did not help


    i am also trying to create a share on my system disk (i don't actually want to share anything on that folder but use it for virtualbox images). however I am lost with the UUID part.


    I have create a /OMV-data folder
    then under media i created a dummy UUID 123e4567-e89b-12d3-a456-426655440000 (the post said i can use any UUID i want...)
    then created the symlink, but i cannot see the volume in the 'add shared folder' menu... any suggestions?

    for the record, it does not really matter to me if i set up my NAS using OMV 3 or OMV 4. what matters to me is that i am using the latest debian distro instead of the outdated jessie repos. stretch is already outdated as well but sadly, that's what you get with debian. heck, i would even upgrade to sid. i wish omv was based on archlinux or at least ubuntu...

    it seems that publishing a simple roadmap on the web with general milestones for OMV4 & 5 would solve a lot of questions on the forum...


    @Wek, i am in a similar situation than you, planning to migrate my windows server to OMV in the next week. I am decided to go already with 4.x. What I like about OMV is that the user data and the system are separated, so later on i could even remove OMV and go with just plain debian or ubuntu

    I am also missing a more detailed description of how mergerfs works. I understand that contrary to JBOD, merged filesystems remain accessible on their individual level as well and if i remove one drive from the merge the rest is perfectly readable. However how is mergerfs handling large files in a single share spanning over multiple disks?