Posts by markmarz

    Update 6/9/20 (final update): Tried re-installing OMV5 on my backup server and none of these problems appeared. So that's a clue. Did another fresh install of OMV5 on my production server and boom! all my difficulties vanished. Can't explain it. Just updating this note in case someone runs into similar problems. Wish I could give a more definitive answer as to what was fixed by starting over.

    Update 6/7/20: Turns out the attempt to alter contents of /etc/resolvconf was wrong-headed. OMV5 uses systemd-resolvd not resolvconf. There were therefore no contents in /etc/resolvconf which is why my initial

    echo "nameserver" >> /etc/resolvconf/resolv.conf.d/tail

    failed and my subsequent clueless

    echo "nameserver" >> /etc/resolvconf/resolv.conf.d

    apparently worked but actually accomplished nothing. Can't explain why these steps seemed to fix domain resolution (briefly). Hallucinations?

    Tried the fix here: SOLVED Upgrade from OMV 4 to OMV5

    sudo systemctl disable systemd-resolved.service
    systemctl stop systemd-resolved.service
    sudo rm /etc/resolv.conf
    sudo vi /etc/resolv.conf
    systemctl start systemd-resolved.service
    sudo systemctl enable systemd-resolved.service

    .. using both and; still no joy.



    Sadly, failing again with exact same DNS issue. Can't explain how it could revert; perhaps I rebooted? Not that that explains anything.

    Well, I for one am putting this on the back burner. I have another machine running OMV4 that has none of these issues and will use it for this sort of network access (NzbGet, etc.) until I feel ready to start pulling hair out again.

    I'm just leaving this dispiriting note so no one is disappointed that the fix shown here doesn't last. For now.

    Thanks for the tip re translator, I should have thought of that! Duh! I checked out Update does not work - DNS problem and at the very bottom found this:

    I answer to myself:

    after reading the test thread again, I noticed a configuration change that I had to make earlier in a different context because a similar problem had occurred. The bug was then under OMV 2.0.x and has apparently persisted until today.

    You have to do the following:

    echo "nameserver" >> /etc/resolvconf/resolv.conf.d/tail

    You can also enter other servers instead of the Google DNS server; I once tried the DNS servers from Open-DNS, they also work the same way. You can also edit the file /etc/resolvconf/resolv.conf.d/tail with WinSCP ...

    and then restart the server.

    root@omv:/etc/resolvconf# echo "nameserver" >> /etc/resolvconf/resolv.conf.d/tail
    -bash: /etc/resolvconf/resolv.conf.d/tail: No such file or directory
    root@omv:/etc/resolvconf# echo "nameserver" >> /etc/resolvconf/resolv.conf.d
    root@omv:~# cat /etc/resolvconf/resolv.conf.d

    I rebooted and it works!! If you could explain what the heck is happening here I'd really appreciate it!

    Also if you could please explain how the DNS setting in my router works with or against the OMV DNS setting. I haven't changed the router setting since I can't remember when.

    Thanks so much for your help! I don't know what I'd do without this forum.

    Hi - Hope I picked the right sub-forum for this. Just did a clean install of OMV5 and installed Docker for nzbget using pretty much the same parameters used for the same container in OMV4. Only some paths changed.

    I have 3 news servers configured in nzbget and every one of them fails if I use their regular domain names, but succeed if I use their corresponding IP address. This leads me to think it's a DNS issue. But I think DNS is configured properly. I have tried the Cloudfare DNS ( and google ( Makes no difference.

    root@omv:~# host is an alias for is an alias for has address has address

    I've put in a ticket to Usenetserver but I'm not expecting a lot of help. It's not really their problem, just verifying configuration with them.

    Any ideas?


    Mark M.

    PS: I did find one fairly recent posting about DNS problems but unfortunately I can't read German.

    Hi - I read somewhere that when installing OMV clean (whatever version) that the underlying Debian is not a 'full' install of Debian. Whatever that means.

    That's not true, is it?

    Related question: If after installing OMV (whatever version) I wanted to install something without the use of a plugin or docker, just a straight install to Debian, there are no constraints on doing that just because OMV is also installed. Right? If it matters, Plex is my main focus.

    I've been using OMV for years and am very happy with it. But now that I'm considering migrating from OMV4 to OMV5 I want to be clear on any constraints or gotchas. Thank you!

    Thank you! I had the same idea and found that ALL of the 1.8GB in /tmp was used by Plex! That was a shock.

    And it so happens that there's an active discussion right now between customer support and engineers in the Plex forum about what broke /tmp usage and how to fix it. A big part of the discussion is how users are supposed to designate where Plex puts his temporary files, since some of the long prescribed ways in fact don't work!

    But I found one way that did work, so I'm using it for now. Just putting the information here in case someone finds it useful:

    Add following to override.conf in /etc/systemd/system/plexmediaserver.service.d:



    Oh, and just to be ultra ultra clear, the dir after TMPDIR= is wherever you want your Plex temp dir to be. This is just an example.

    I think I'll go ahead and double my RAM to 8 GB anyway. Just for jollies and it's cheap.

    Thank you! I will get some more RAM. After I do that, will it still be necessary to increase the size of tmpfs or will it detect the new RAM automatically? My guess is the latter since there is no size specified in fstab now.

    One more followup, please: since I'm filling up 4 GB rapidly, I expect that I'll fill up (say) 8 GB almost as quickly. Does it make sense to (somehow) point /tmp to a fast NVMe drive with plenty of capacity to avoid further problems? If it does, a hint how would be appreciated.

    Thanks again!


    This morning I got this message in syslog (since lost):

    anacron[14203]: Can't write to temporary file: No space left on device

    I ran df . -h and got:

    Is there something I can do to expand the size of /tmp?

    My understanding (shaky) is that /tmp is actually mapped to RAM on Debian. I currently have 4 GB RAM. I understand I could put in a cron job to periodically clear /tmp, but that's probably not safe for running processes. I verified /tmp is cleared on reboot.


    Mark M.

    I have a setup just like what you want, except I'm using a spinning drive for boot. I set this up a while ago, so I'm working from memory. I don't recall having any difficulties in setting this up, and no problems accessing the data partition. Perhaps you did something different than what I did:

    • Installed clean OMV4 on 1 TB spinning drive using ext4 (which can be shrunk).
    • Booted from Partition Magic USB so I could create a new partition, also ext4, on the boot drive. Of course this meant I had to shrink the OMV installation. I chose 10 GB for OMV partition, the rest for data partition.
    • Gave new partition a label: bootdata
    • Rebooted into OMV4 and saw the 2 partitions in Storage->File Systems
    • Mounted the new partition.
    • Installed Plex and pointed to the bootdata partition for the library.


    • Capture.JPG

      (39.97 kB, downloaded 219 times, last: )

    I have had Plex installed for quite a while from OMV 2.* to OMV 4.*, haven't noticed any slowdown for file transfers, though I don't use FTP. Generally rsync.

    I don't really have a clue what could be causing your slowdown but if it were me, I'd try uninstalling Plex first and see if that makes a difference. If you have a lot of Plex metadata play it safe and rename or copy the plexmediaserver directory to ensure it isn't wiped when you reinstall, though I don't think (think! hah-hah!) it will be.

    Good luck!

    Since you pointed me in the right direction, I installed the OpenVPN plugin on my NUC and port forwarded 1194 to it and it works beautifully! My test was to create a client .conf file and import it into the OpenVPN app on my android tablet. Then I went to the local library and was able to access my LAN from their network using RDC without a hitch. Love it! BTW my router doesn't support VPN install. But since I only need VPN for this single use case I don't see why I'd want to put all traffic through it anyway.

    Ultimately I'm going to ship the NUC across country, but now that I'm using a Dynamic DNS provider in combination with ddclient on the NUC, I'm confident the DDNS will be updated with the new external IP within 5 minutes of booting. My brother will assign a permanent internal IP to the NUC and port forward 1194 to it. Should work, I'm excited to try it out!

    As far as user based access, yes I think it works that way. When I generated a certificate with the plugin (so easy!), I had to select a user. It offered my own user account as well as the OpenVPN system user. I chose my own user id. It may work as well with the OpenVPN user id but I'm not all that curious since it works as is.

    When I was running OpenVPN on the RPi, everything worked smoothly as well. Speed was fine, I suppose when it's crossing 2,000 miles it wouldn't be as fast, but that's the internet not the RPi. But then I realized unless I shipped the RPi to my brother as well, it wasn't really going to work for my purpose. Your suggestion to put it on the NUC answered multiple questions.

    Thanks for your help!

    I've set up OMV on a NUC with RDC and Plex plugins. Works just fine! But it's on my LAN and I want to send the NUC 2,000 miles away to my brother's house. I know I'll be able to administer Plex (to a limited degree) with the Plex web interface no matter where the NUC resides without any further changes. But I'm sure I'll have to do something to use RDC to administer the NUC remotely. That is the only reason I'm using RDC now by the way, just to test out using it to administer the NUC. Normally I use SSH on my LAN.

    I've experimented with Teamviewer but had a rough time since the NUC is headless. Ditto RealVNC. No such problems with RDC plugin.

    I'm ignorant about most network stuff, though I'm trying to change that. Hardly know where to start, can get very confusing right quick. One thing I read was if you want to use RDC remotely you should do so through a VPN. Well, I installed OpenVPN on a Raspberry (with PiVPN) just for that purpose and OpenVPN works, but I really don't know next steps or how to use that with RDC once the NUC has moved.

    My guess is I'm going to need to know the external and internal IP addresses for the NUC after it's hooked up to my brother's network. I'm sure I can put together a script that will email that information to me at boot time. But then what??? Hah-hah!! I'm really a dummy on this stuff. There's a lot of books I could read and I've certainly been hammering on Google, but I need a little guidance to get on the right road.

    Any suggestions would be very much appreciated!