Posts by cubemin

    I'm sorry to hear about your troubles. Going by the specs listed in your signature, it sounds like the 5-bay USB enclosure isn't playing nice with the Pi4. Or one or more of your disks are actually on the brink of dying, causing OMV to automatically remount the filesystems on said disks as read-only in an attempt to prevent damage to existing data.

    These are just a couple of possible reasons I can think of; a lot of people use USB drives as permanent shares but that's just not for me - give me native SATA any day of the week. (I'm running both a custom-built Intel server PC and an ODROID-HC4 - no USB whatsoever.)

    "Two disks seem to occasionally appear as read only," do you mean while accessing them from Windows via Samba - as in, you can browse and read files but not create/delete/modify them - or is OMV itself showing the filesystems as read-only?


    I will say OMV does have a bit of a learning curve - the userfriendliness (or should I say hand-holding) of something like Synology's DSM or QNAP's QTS software isn't really there - but OMV does make a lot of tasks simple enough which would otherwise be a Linux commandline nightmare for any non-expert.


    Don't be discouraged too soon - stick with it and you'll be surprised just how much you learn in the process of managing your OMV system and settings things up exactly the way you like. I've learned more Linux in the past few months than in my whole life before, and the time investment has definitely been worth it.


    Besides, OMV is 1. free and 2. completely under your control, with no proprietary code, no backdoors and no privacy concerns. It really is an amazing piece of software once you learn all the ins and outs of it.


    Emby, by the way, is very easy to install and run on OMV, either as a Docker container or on the system itself (which is what I've done). I'll be happy to guide you along the way. :)

    I'm not in the habit of resurrecting old threads, but just wanted to mention I happened across a solution to the issue of overly large 'dd' backup files (while doing something completely unrelated). ^^


    Turns out my SSD hasn't been TRIMmed since the system was first installed because the fstrim.timer service was disabled. So I issued systemctl enable fstrim.timer (for those unaware, this sets up a weekly TRIM of all existing filesystems every Monday at midnight).


    I also ran systemctl start fstrim.service to immediately TRIM my SSD and then ran a new backup. Bam! Much, much smaller now and reflecting the actual filesystem usage of my system. :)

    I believe I found a solution. Well, at least a workaround.


    I edited the file /srv/salt/omv/deploy/monit/services/files/nginx.j2 containing:

    Code
    {%- if not webadmin_config.forcesslonly | to_bool %}
    if failed host 127.0.0.1 port {{ webadmin_config.port }} protocol http timeout 15 seconds for 2 times within 3 cycles then restart
    {% endif -%}
    {%- if webadmin_config.enablessl | to_bool %}
    if failed host 127.0.0.1 port {{ webadmin_config.sslport }} type tcpssl protocol http timeout 15 seconds for 2 times within 3 cycles then restart
    {% endif -%}


    and changed this part: timeout 15 seconds for 2 times within 3 cycles

    to this: timeout 25 seconds for 3 times within 4 cycles

    There are two occurrences, one for HTTP access to the GUI and one for HTTPS (SSL/TLS). I changed both to remain identical to each other.


    (You could choose higher numbers, but it would then take even longer for nginx to be restarted if it does hang. On the other hand, that would actually highlight a problem with nginx itself...)

    After that, I ran omv-salt deploy run nginx and let it do its magic. This will permanently update the file /etc/monit/conf.d/openmediavault-nginx.conf to reflect the new monit/nginx configuration.


    So far, so good... no nginx alert emails yet. Hope I didn't jinx it just now. :)

    I had a very similar problem renewing my certificate a while ago. (Same as the OP, using certbot from the commandline.)


    The solution in my case was to forward port 80 in my router to the server.


    That seems like a bad idea at first... however:

    I forward public port 80 to a custom local port, which I have certbot configured to listen to (instead of local port 80). And the only time anything is there to respond to incoming connections to public port 80 is when certbot is running a renewal, so at all other times port 80 is 'closed' despite the forwarding as nothing is listening on it.


    At least that's how I understand it...

    Did you ever wipe the two drives in question before creating filesystems on them? That should fix things up for you - OMV will also get rid of the "msdos" partitioning and use GPT instead.

    (A 'quick' wipe from the OMV GUI will be sufficient, don't spend hours waiting for a full wipe.)

    Well, first of all, don't use sudo if you're already root. ;)


    Second, do you have your OMV GUI on port 80? If so, change it - otherwise certbot is unable to spin up its own web server on the same port for authentication. Or use webroot instead of standalone.


    Other than that, I don't have any ideas... unless your router is interfering with port 80 forwarding for some reason. (You don't need 81 and 443, btw.)

    Since I have a monthly system backup set up in OMV and it runs the command /usr/sbin/omv-backup, I was wondering if omv-backup accepts any commandline options to reduce its verbosity.

    I have the option to send command outputs to email enabled, and would like to only receive a summary once the backup finishes. Right now, I get very long emails with running percentage and Mbyte numbers - the kind that, if displayed in a terminal, continually updates a single line (which obviously is impossible in an email).


    Bonus question: what other OMV-specific commands are there besides omv-backup, omv-upgrade, omv-firstaid, etc.? I haven't been able to find a complete list of them anywhere.

    Sounds like the ASUS board was just defective - nothing to do with Linux or OMV at all.


    The Supermicro board should work very well. Again, there's no obvious reason why OMV shouldn't work on it.


    Also, OMV5 isn't a Linux OS in and of itself. It runs on top of Debian (current stable version codenamed "buster").

    Hmm. I see no reason why OMV wouldn't work on either mobo.

    The ASRock one seems to have two separate Intel NUCs, are you sure neither of them was working?

    As for the ASUS one, it would help to know what exactly you mean by "kept complaining about RAM." What was the specific issue, and at which point did you run into it?

    Check that your network in windows 10 is set to private. By default it sets to public which can cause issues with network shares.

    Choosing the public setting for a network simply disables network discovery and file sharing. It's not a separate setting, more of a "default" scenario. The OP stated that discovery and file sharing are turned on.


    Possibly it may be Windows' own firewall interfering with access to 192.168.1.9. That would be the next thing to look into.