Beiträge von HotBlack

    I think that would be a truely awesome idea! I would certainly be happy to contribute some container templates.


    Would it make senese to have some sort of "variable subsitution" in the compose files?
    I am thinking something like:

    1) Another tab in plugin which lets you define variables and strings they resolve to (e.g. %PID is replaced by '1003'), a user would fill these out the way they want them.

    2) You download a template, and the templates which follow some sort of OMV standard, would use the same set of standard variables.

    3) When you run docker up, the file is preprocessed and the varibales are swapped with strings or an error is thrown if a variable is used but not defined.


    The idea here is that it would save users havng to explcitly define things like the same shared volume full of movies refered to in many containers and hopefully make it easier for users to get basic conatiners up and working.

    Would it be possible to include option to add a text box that allows for adding arbitrary upsmon.conf directives?


    In my case its specifically iPOLLFREQ, POLLFREQALERT & DEADTIME that i want to set, and full text boxes for these would be nice, but to accomodate more users just letting users add directives to the upsmon.conf file would be nice. As the file in managed by OMV, just editing the file loses changes when something is later changed in the UI.


    Those 3 values are key to getting quite a lot of older UPSs to work, many of which which don't support the frequent polling which OMV sets in the upsmon.conf file.

    That is also a great approach, in particular for this plugin.


    In general it would be nice if every plugin page had a link to a page in the omv-extras wiki, as quite a few plugins need more explanation than can easily fit within the plugins UI.

    ...

    What kind of additional note would explain that better? Since it doesn't say anything about mountpoint, I didn't think people would think they were selecting a mountpoint. And the part about converting to Paths made me think it made sense. But we know my brain doesn't work the same way as lots of OMV users lol.

    ...

    Well I am by no means an expert at writing documentation/UI design, but here are a few suggestions that I think are considered good practice:


    Those are just some ideas, and it does seem that everyone, but me figured it out without any help so it may well not even be needed.

    Thanks for the explanation, maybe just update the text in GUI that it is intended for legacy support and could be removed in future versions.


    In terms of missing documentation I was a bit confused by the shared folder option, assuming at first I had to give a shared folder where I wanted to the drive pool to be mounted as opposed to it being an option that let me include shared folders in the pool.


    Is it correct that you cant choose where the drive pool is mounted, i.e. that the mount is always in /srv/mergerfs/[name of pool]? (obviously you can then symlink to the pool if you need paths to it other places)


    All in all I am very impressed with the new plugin, for the first time ever I have been able to get OMV setup the way I like it without having to manually edit fstab.

    For others that may encounter this issue, it appears this is the result of a single setting in my router. I had enabled ipv6, but disabled DHCPv6.

    ...

    Once the ipv6 setting was off (or conversely the dhcpv6 server switched on) everything worked.


    I think that the presence of RA signals the Debian net cfg code to persistently try to get an address, and that may be a bug in that it just doesn't support the so-called 'router only' mode, but I've more reading to do about ipv6 before I can be sure.

    Thanks I had the same issue and after checking cables and trying different install images, found this thread. Thanks.


    It would really be nice if the OMV installer mentioned the issue during install.

    Some are but why would they need to be? 4.x repos are ready.

    I had issues with proftpd-mod-vroot. I had to specify to install the 0.9.4 version from the debian stretch repos since the 0.9.3 version was pinned higher in the omv repos. You might need to manually install omv-extras 4 as well. I haven't had much time to keep testing upgrades. Without knowing what plugins you use, it is hard to give more advice.

    Thanks for the info. I was not aware that 4.x extras repos had been created. The specific plugins I am using are:


    • openmediavault-apttool 3.4


    • openmediavault-backup 3.6


    • openmediavault-couchpotato 3.2.2


    • openmediavault-fail2ban 1.3.1


    • openmediavault-keyring 1.0


    • openmediavault-omvextrasorg 3.4.26


    • openmediavault-resetperms 3.3


    • openmediavault-route 3.1.4


    • openmediavault-rsnapshot 3.9


    • openmediavault-sensors 3.0


    • openmediavault-sickbeard 3.2.2


    • openmediavault-snapraid 3.7.1


    • openmediavault-symlinks 3.1.3


    • openmediavault-unionfilesystems 3.1.17


    Kan you indicate which are available/have issues on 4.x, that you know of?

    I am think of moving from 3.0.88 to 4, mostly due to wanting to run some things that require moving to Debain 9. I can't seem to find any guides and only one forum post noting issues when upgrading.


    My my main concern is loosing data in a large 24 disk snapraid array. My disks are mounted in a mixture of /media and /srv (newer disks in /srv, but the snapraid array combines drives from both) Are there any known issues?


    These days I run very few plugins and almost everything I run on my NAS is done through docker, but are 3.x plugins still compatible?


    In fact if anybody has any useful info I would be very grateful to hear how it went. I am planning to simply take the omv-release-upgrade route.

    Does anybody know what the status of the 3.0 branch is? Is anybody using it for everyday use. What is/isnt working? Is there a list of plugins that are working under 3.0?

    @'tinh_x7: Could you say a little more about how you did the installation? Did you use the nginx auto install feature of the letsencrypt client? To what extent does the clinet handle auto update of the certificate?


    Overall lets encrypt seems to be a great idea for a OMV plugin, the whole point of letsencrypt is to have short life time certificates (90 days) that are then automatically renewed using their client (see https://letsencrypt.org/2015/11/09/why-90-days.html). Ideally an OMV plugin would handle regular running of the client and possibly add the certificate to sickbeard, couchpotato and even ssh. Could it be added to the plugin wish list?

    mhddfs segfault "transport endpoint is not connected"[/url]']Here is the package. If it fixes the problem, I can put this in the repo.


    Is updating the repo possible? I have been running the 'no-segfault' version for quite a while now and have not seen the "transport endpoint is not connected" once. It does seem that the pooling plugin is much more stable in MHDDFS mode when making use of this package.