Posts by _DD_

    Those directions I gave you were my own saved directions that I use for my setup. Nothing sketchy going on, that's just a link to what is probably CyberPower's CDN for downloads. I was trying to save you time by not finding it yourself but since you have found it just look at the download link for the power panel business edition. You should see it's the same as I gave you unless their CDN adjusts for geographical changes.

    In fact I run my own web hosting company and constantly fight against people trying to hack and attack my customers. I wouldn't give anybody instruction unless I knew they were safe and tested myself.

    If you login to SHH it should take you to your root folder. That's where the file should've been downloaded to originally unless you changed directories first. Just run a "ls" command and you should see the file. If not then chances are you never downloaded it and that's probably why the installation failed. Or you might have needed a 32 bit instead of the 64bit I gave you but it looks like you resolved the plugin issues anyways.

    I have that same UPS. You might have a bad USB cable or port. Try a different USB port at the board and/or swapping cables to eliminate those possibilities.

    I've used the NUT plugin in the past and it worked fine for me. But I've switched to using CyberPower's supplied software for monitoring. If you've eliminated the hardware then maybe try uninstalling the NUT plugin then installing CyberPower's software. It is fairly easy.

    Open a session in SSH.

    chmod +x
    ./ -c

    Follow the configuration wizard.

    Then open http://{server_IP}:3052 in a browser to access it. If you've setup firewall rules in OMV then you will need to allow 3052 TCP in. If you haven't setup firewall rules then it should already be open.

    Yeah man you can't run that public IP subnet as your internal network and expect things to work right.


    Use an appropriate private network.

    Would be like trying to replace an engine in a Chevrolet with a Ford engine because they are both engines. It just doesn't work that way without a lot of extra work and even then things just aren't going to work like they should.

    Hi _DD_, even I give access to Plex directly to the internet, no one will be able to come through?

    This is why I asked if it was behind a home router or was a public internet facing machine. If you have it directly accessible to the outside world then yes you need to setup your rules properly. But your rules don't make much sense even if it was facing the internet directly. So I would advise against doing that (i.e DMZ) and just forward the needed ports in your router. Much easier for you as far as work needed to do and the end result is a much safer machine.

    Do us a favor though. Login to your OMV through an SSH session with putty and post a screen shot or the copy and paste the output of


    Since it sounds like you're behind a HOME router, your rules don't make a lot of sense with allowing that whole 256 IP public subnet. Your router is going to be doing all of the blocking from the outside world anyways.

    By default everything is open in OMV firewall. So I would just delete all those rules in OMV and not worry about them. Let the router do all the blocking and just forward Plex ports to your internal address of the OMV machine. Unless you have a reason not to trust other users on your home network or if you have a very insecure home network to begin with.

    Okay for fun I went ahead and installed the clamav plugin in my home OMV. I don't know if this is your issue or if it's isolated to just me but I ended up with all sorts of errors and the plugin not working. Not even an apt clean and remove and reinstall of plugin did the trick. I'm on OMV 2.2.13 if that matters.

    I tried a manual installation.

    apt-get install clamav clamav-daemon
    clamscan -ri --exclude='\.(mp4|mkv|avi)$' /media/b8ba8cc5-6d26-4a00-8dcb-9a8907a871fe/*/My Videos

    It scanned 200GB of videos in 11 seconds. So the syntax is correct for clamscan. Although I don't know if it's correct for the OMV plugin or if maybe there is some sort of issue with the plugin or you're having a completely different issue. You could always install it manually and just create a cron job to run at your desired time.

    I don't use the clam AV plugin in my home OMV but I use clamscan on my cPanel servers as a cron job. I would imagine this will work by adding either of these in the "Extra options" box of OMV's clam AV plugin.

    If you just want to tell it to simply skip certain files by extension add this edited to your needs. This is what I use.


    Or via the clamscan man pages to set max file size to be scanned


    Extract and scan at most #n kilobytes from each archive. You may pass the value in megabytes in format xM or xm, where x is a number. In other words replace #n with like 100mb or whatever max file size you want it to scan.

    If that doesn't do the trick in the "Extra options" box then you may want to run it as a cron job with those commands.

    UFW is just a frontend for iptables. OMV does have it's own frontend for iptables in the webGUI under the network tab. It kind of sounds to me that UFW is clashing with OMV for some reason or another. I would remove UFW and just configure your firewall through OMV's webGUI to see if that solves your issues. Also, double check your network settings while you're there.

    Let me add my 2 cents before you give poor old gderf an aneurysm lol. He's right, those 1st 2 rules are buggering the rest of your rules.

    Rules are read from top to bottom. When it matches a rule, it then STOPS reading the rest of the rules. So what you're doing is allowing all ports from all IPs as long as they are established (3way handshake) or related (to another rule). This makes the rest of your rules moot.

    By default everything is open when you first install OMV. iptables -L command will confirm this. So you want to set up all your ACCEPT rules first per port/IP then DROP everything at the bottom. You can do REJECT but DROP is better. Reject sends a packet back to let the source no hey you're not allowed. Drop just drops it like nothing was there to being with which is why it's considered safer.

    Personally, since it sounds like you only have 3 or 4 IPs that need access. I would just allow all TCP/UDP ports to each IP source then drop everything else instead of setting up custom ports for each service. But either way works.

    If it's all working except for your Androids then have a look here. It's been a known issue for about 6 years now with droids that doesn't seem like it's going to be fixed. From what I've read on it, depending on your version, you might be able to root it and do some editing of some files to get it resolving local domains but I wouldn't get my hopes up.

    Windows computers advertise themselves to other Windows computers on your home network via WINS. That's why you can connect locally via hostnames from 1 Windows machine to another Windows machine across your home network.

    To get .local names to resolve you will need to run your own internal DNS and configure the .local zones accordingly. Now you might be able to do this from your router if you have a high end router or one with a custom firmware like DD-WRT. Although I'm not 100% sure high end routers will even do that without custom firmware. You would just have to look and see if it's possible. Otherwise run your own local DNS.

    Here's what I did to give you some insight on how to get it working.

    Setup a CentOS7 Virtual Machine that runs 24/7 with static internal IP

    Installed BIND

    Initially setup internal DNS zones by hand via WinSCP but I did install Webmin later which also allows for DNS zone editing

    Edited all the NIC settings on all local computers to use the VM as the DNS resolver.

    That was the gist of it. It works well from all my PCs and iPad. The only thing giving me issues is my Android phone. Apparently it doesn't like to resolve .local domains without rooting it and being able to edit /etc/resolv.conf. But at home, I really don't need to access anything via a local domain name on my phone anyways.

    Here's a tutorial I found with most of the steps to follow and how to add DNS zones. The tutorial explians how to setup a master and a slave DNS but I only setup 1 DNS (master) for my purposes. Also, very importan step left out of that tutorial is to edit /etc/named.conf and add forwarders for DNS resolution of regular external domain names. so if you do follow that tutorial add the forwarders line at the bottom of this:

    options {
    listen-on port 53 {;;};
    listen-on-v6 port 53 { ::1; };
    directory "/var/named";
    dump-file "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query { localhost;;};
    forwarders {;;};

    Those are google's DNS. You can use your ISP's or any other DNS provider if you wish.

    VNC is for displaying a desktop environment. To use VNC with OMV, it would be a 3 part install. You would need a desktop environment installed on your OMV, the VNC server software installed on your OMV, and finally client software on your android. OMV 3 does have a remote desktop plugin but I'm not sure how it would get along with a VNC server.

    That login screen you talk of with a monitor plugged in is just a glorified shell terminal. So you basically could achieve what you're after by installing an SSH app on your android device.

    According to your own post here you're running your NAS on a HP NC6400 laptop. As stated in that thread, bad idea from the start. But that particular model has a release date on May 2006.

    Hate to break it to you but your old outdated hardware is the issue. No amount of software changes will live up to your performance expectations of a 8/9/10 year old laptop running as a NAS.

    I had a very similar issue about 6 months ago with losing my mapped drives from Win10. I don't remember the exact cause, just remember I found the fix at this link using the Method 2 registry edit.

    Method 2:
    The long-term fix is a registry edit that will make mapped drives visible in both standard and administrative sessions.

    [*]1. Press Windows +R and type in : regedit
    [*]2. In Regedit, navigate to HKLM//SOFTWARE//Microsoft//Windows //Current Version//Policies //System.
    [*]3. Create a new REG_DWORD entry named "EnableLinkedConnections".
    [*]4. Set its value to 1.
    5. Reboot after adding the registry entry and programs will be able to see mapped drives forever

    Haven't had an issue since.

    Cannot load /usr/lib/apache2/modules/ into server: /usr/lib/apache2/modules/ cannot open shared object file: No such file or directory

    Right there it tells you is missing. Try installing it:

    apt-get install libapache2-mod-php5

    Why can't Nginx & Apache2 get along?

    They do get along. It worked right out of the box for me on a fresh install of a test VM of OMV.

    Maybe you're missing an update on your current OMV box? Maybe you've tried something along the way that removed the Hard to say for sure.

    If you worried about trying these things on your original OMV then my only other advice would be to create a test VM, install apache2 to it and then start comparing the two.