Posts by cubemin

    apt-tool will not find emby-server because it isn't in any of the stock OMV repos.

    Whoops. Hadn't thought of that - I must have added more repos and forgotten about it, because I seem to be able to find a ton of stuff via apt-tool. ?(

    I have two external HDDs and one backup job registered in the USB Backup plugin for each drive.

    That way, by plugging in drive A it backs up one set of shared folders, and with drive B, a different set. So far, so good.

    Question: if I use both drives simultaneously with a USB docking station and plug it in, will USB Backup run both backup jobs concurrently, or one after the other?

    I would try it myself but I'm afraid they'll start running at the same time and cause disk thrashing (and take forever to finish).

    Sounds pretty good to me overall. A few thoughts:

    Rsyncing DeviceData to Storage every 10 minutes is excessive IMHO. Once a day or maybe every 12 hours should be plenty. SSDs are pretty reliable, and your DeviceData already serves as a backup in itself, namely of the data on your phones, etc.

    Similarly, I wouldn't bother backing up Storage more than once a week, maybe every other day. It's a question of "how much is your data going to change between backups, and how much recent data since the last backup can you afford to lose, given the worst-case scenario?"

    I can't think of a simple method to sync two shared folders in realtime right now, but I can answer your other question about rsync - if a new rsync job launches and notices that another one is still running, it will silently exit and not interfere with itself. (Tested this myself.)

    Method 1 - Command line

    Go to the Emby server download page and select Debian from the dropdown menu. (Alternatively, you can grab the correct Debian package directly from the Github page.)

    Copy the downloaded file from your PC to the OMV server (simplest way: to any shared folder).

    Open an SSH terminal and log in as root. Browse to the folder containing the package file and execute

    dpkg -i emby-server-deb_<current version>_amd64.deb

    replacing <current version> with the actual version number, which as of the time of this post is

    When the installation completes, Emby Server will be up and running. Open a web browser to http://<your OMV server IP>:8096 to set up Emby.

    Method 2 - Apt tool (OMV web GUI)

    Open the web GUI. If you don't have Services/Apt Tool yet, go to System/Plugins, then find and install openmediavault-apttool.

    Now go to Apt Tool. Select the Search tab and enter emby-server in the search field. Click on Search Repositories and highlight the entry it finds (there should only be one). Click on Add to Packages Tab.

    At this point, emby-server should show up in the Packages tab. It won't! You'll need to force the Apt Tool plugin to refresh by going to any other OMV menu (doesn't matter which one), then back to Apt Tool.

    Now, highlight the newly added emby-server again, and from the Tools sub-menu select Install.

    I thought it was not recommended to allow Emby and Plex to delete?

    That's the first time I've heard about anything like this. :huh: (Or ever had an issue like it!)

    Of course, it only further demonstrates the importance of a true backup, for one thing.

    The other is - I can't imagine that Emby is so badly written it would ever delete entire libraries without user error playing a role in it. It also lets you disable permission to delete (and only delete) any media files on a per-user basis - meaning Emby user profiles, not OMV system users.

    Correct me if I'm wrong, but on a system level (access permissions for users/groups and ACL lists), you can't enable write (create) and delete permissions separately, can you? It's either be able to delete, or be read-only... only.

    I had the same issue. To fix it, I went to Access Rights Management/Shared Folders in the OMV web GUI, selected the shared folder containing my Emby libraries, clicked the ACL button and then checked the user/group permission boxes for read/write next to the emby user and group.

    That gave my Emby installation full permissions to read, write and delete media files.

    I should add that I run Emby directly on the system, not as a Docker container. I don't know if Emby creates a new user for itself when installing within Docker, but you could do this manually, then run the Docker container as that user and proceed to set ACL permissions as above.

    Edited /etc/cron.d/mdadm and replaced 57 0 * * 0 with 56 23 * * 2 (Tuesday at 11:56 p.m.).

    Then issued

    echo 120000 > /proc/sys/dev/raid/speed_limit_max
    echo 40000 > /proc/sys/dev/raid/speed_limit_min

    to limit resync speeds to between 40MB/s and 120MB/s.

    Guess I'll find out how well it works on February 2nd. :)

    ... but HBS 3 (QNAP Hybrid Backup Sync App) can handle one share per rsync job only:( ..

    Hmm. I had a QNAP until recently and I had one HBS3 sync job covering multiple shares. Pretty sure you can add more than one share via rsync, too. Check again if you missed something like a "+" button or similar?

    (Not wanting to take away from your neat solution for ProFTPd! Just wanted to point this out.) :)

    If I want to remove Clonezilla, etc. from my OMV system, is it safe to simply SSH in and delete the .iso images in the /boot folder? Or will that potentially mess up GRUB?

    So, wait - let me just get this straight.

    Cockpit used to have a Docker plugin? (I never really paid attention as I use Cockpit to manage VMs and Portainer to manage Docker containers).

    I installed all the updates from the OMV web GUI except the cockpit-docker plugin as suggested, and that worked fine. It also made cockpit-docker vanish from the updates list by itself.

    So that's it, right? All is good?

    I'm thinking about using sedutil to encrypt the SSD that I have OMV installed on. It's a Samsung EVO 970 Plus NVME m.2 drive with two partitions (system and one with a shared folder on it).

    My goal: to have data-at-rest protection so that when the server is powered off, everything is safe and locked away. (My storage HDDs are already LUKS-encrypted and automatically unlocked when OMV starts up.)

    I know I would have to attach a keyboard and monitor to enter the SED password at bootup time (only from a powered-off state), and I'm aware that the system is unlocked as long as it's running. That's OK - I just want "no-power" security.

    Is there any reason not to run OMV on a system drive with active SED encryption?

    I know I'll have to do this carefully, step by step... take the server offline temporarily... and make a complete backup first, just in case. I don't mind, though.

    Thoughts welcome and appreciated.

    * bump* Another resync getting in my way on a Sunday. I really, really would like to be able to change the resync schedule (without OMV changing it back).

    Not necessarily to reduce its frequency, but to move it to a better time, say, a weekday early morning.

    Please? *puppy eyes*

    You're right. I suppose I'm spoiled by the way Windows imaging software takes a volume snapshot and only copies blocks in use by the filesystem, not a forensic image of the entire partition.

    I guess I was just more surprised that unused blocks on my OMV (ext4) partition (which is to say, non-zero blocks) piled up so quickly. Must be a result of log file rotation and temp files, etc.

    I'll look into fsarchiver etc. and see if they suit my needs better. Thank you. :)

    I'm a Nicotine+ user, and there have been several updates to it in the last few months alone.

    I can't help you with your issue, but for me personally, a VM running the "real" Nicotine+ client along with Private Internet Access (or any other VPN setup of your choice) has been the perfect solution. I'm using Linux Mint "Tricia" (v19.3) and CPU usage is very light, although you'll want to set aside some 3-4GB or so for the VM.

    Just thought it would be worth considering instead of the docker route...