Posts by luxflow

    encryption: I used letsencrypt to generate an SSL cert for remote access; I created OMV self signed certs for each lan service

    I'm not sure why you do, I think there is no difference self signed vs letsencrypt cert for lan services since either self or letsencrypt
    it should be added trusted cert by manually to all of your computer which trying to lan services

    nginx: I created a pair of servers - one for remote; another for lan. In all servers, I am using SSL on 443 and selecting the appropriate certificate

    try your Server name : emby.lan
    to manage only one configuration per service


    I can't get it to work on port 8920. I just get an nginx error. Should I be using this port if I am using nginx with SSL:443/certificate? I have attached my emby nginx settings.

    8920 port should be used when emby uses https (for SNI proxy), so your case, 8096
    you should differentiate meaning between
    proxy server using https and
    service using https or http

    for example, if proxy server uses https and service use http, when user connect proxy server, connection between user and service is https
    1. user < -(https)- > proxy server
    2. proxy server < -(http,https)- > service
    In your case, your service is safe either http or https
    because your service listen at localhost, user in LAN cannot directly access to service, only can access via proxy server

    Usually service don't provide https
    Because usually people use proxy server, and hide their service from directly access (for security reason, and load balacing, easy cert management)

    SNI proxy says it is for
    This enables HTTPS name-based virtual hosting to separate backend servers without installing the private key on the proxy machine.

    But, in your case your proxy machine server and backend service server(emby...) are in same server, so SNI proxy for you is meaningless I think..

    There are 3 options I think

    first of all, In all 3 options, your services should be listen at localhost(
    that means all connection should pass proxy (whatever it is nginx, SNI..) unless connection made from OMV machine itself

    First, very simple, easiest to configure but give up to use

    (2) set up a way of mapping to (which is for lan access);

    instead make `server_name emby.local`
    or give up to use local address, access service only via

    set up omv-nginx for remote access
    and set up omv-nginx for lan access (that means `server_name emby.local`)
    this can be done with omv-nginx UI

    unlike above options, set your services to serve https
    set up omv-nginx for remote access (that means ` localhost:8920`)
    and set up omv-nginx for lan access (that means `emby.local localhost:8920`) note 8920 is https for emby

    also don't forget to setup local dns, such as mDNS, DNS whatever... if you want to local domain
    If you use option second, third one, you will encounter cert security warning this when you connect services from LAN
    unless you manually add cert to trusted cert

    My recommended choices are
    first one or second one

    why are you trying to copy cert not just using reverse proxy?
    just use omv-nginx

    like this..

    1st OMV as proxy server (https) <------------> services on 2nd OMV (http)
    services on 1st OMV

    raid is for availability
    raid is not backup
    for example raid cannot protect user's mistake, virus..
    then why use raid? because of availability
    think about running company, using raid 1 with 2disks
    one disk fail, but it can stil serve service, that means it is available

    so best practice is.. having both availability and backup

    so back to the your problem
    for home user, backup is more important than availability
    my suggestion is grabbing `addition` hard disk (should be seperated hard disk don't put your eggs in same basket)
    and rsync(similar copy, but only changed part is copied) important data to another disk

    hmm try omv-nginx plugin rather than SNI proxy
    it is more convinient sice it has web UI
    I googled some info about SNI proxy and I think you don't need SNI proxy

    so basically set your backend services(emby,syncthing..) to use http (it is default as I know)
    and using nginx as reverse proxy, of course you can assign different port for each backend service

    but I suggest you different hostname for services rather than only changing port if you possible
    rather than,
    I think it is more good practice

    for example, emby listen http://localhost:8096

    so omv-nginx -> server -> add -> follow below setting (change domain, port according to your needs)

    and put it in extras options

    all cert information is stored at /etc/letsencrypt/
    so basic idea is copy that folder to the other omv
    it can be done with scp, or rsync cronjob

    but problem is
    it copy only cert file, don't copy omv configuration
    so you cannot see cert in omv interface

    so you have to make script for adding cert configuration for omv gui

    but don't know why you want to use same cert
    so I cannot give you advice further

    oh I found what's wrong with you

    just type following commands

    git clone
    cd sniproxy
    sudo apt-get install autotools-dev cdbs debhelper dh-autoreconf dpkg-dev gettext libev-dev libpcre3-dev libudns-dev pkg-config fakeroot devscripts./ && dpkg-buildpackagesudo dpkg -i ../sniproxy_<version>_<arch>.deb

    you might wonder why git clone, cd sniproxy is skipped in github page
    that's because usually plugin developer expect user already know this procedure

    although it is.. more like about linux not OMV
    next time, ask in linux forum, or freenode #irc
    you will get better faster answer

    yeah that is nfs share problem will be fixed in next release
    workaround is

    0. unmount all zfs filesystem
    zfs umount -a

    1. ensure your zfs filesystem is not mounted
    zfs get mounted -t filesystem

    1.5 double check there is file in /GHpool to prevent deleting your data
    ls /GHpool
    ls /GHpool/blahblah...

    2. rm -rf /GHpool

    3. remount zfs mount -a

    do you use NFS share for ZFS?
    if so current(3.0.6) implementation has problem, will be fixed (3.0.7) which will be released with omv 3.0.60 (it is not released also)

    if not,
    checkout systemctl status zfs-mount to see why it is not mounted
    zfs get mounted -t filesystem

    I'm considering passing --rsa-key-size argument whenever calling certbot

    What I concern is that changing rsa key size 4096 may be drop supports for older browser
    also as I don't think it is urgent thing to be fixed. it will takes time..

    by defaults, omv redirect all host to admin page (that means,, will be redirected to web gui)

    if you want to add virtual host such as (such as,
    use omv-nginx plugin to add virtual host

    if you don't have plan to add virtual host but change web gui address for admin page
    add OMV_NGINX_SITE_WEBGUI_SERVERNAME="" in /etc/default/openmediavault
    (why this works?, see here)

    you can change chiper for omv web gui as you want (see here)
    so you just add OMV_NGINX_SITE_WEBGUI_SSL_CIPHERS="EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH" in /etc/default/openmediavault
    not to use DH keys

    for RSA key length 4096, should have to chnage omv-letsencrypt to support it
    but not sure when that feature is released