Posts by darkarn

It is one thing to start with a fresh OMV5 setup with Docker, but it is another to transition from an already-working setup with plugins to a new OMV5 setup with Docker

I am specifically using transmission/bittorrent and duplicati plugins for OMV. This OMV setup is in a VirtualBox VM on my Windows machine (will transition to a proper baremetal machine once more parts get delivered etc). I will like to do the transition such that the settings and databases used by the plugins are transferred over properly into their Docker equivalents

I have these doubts that I want to clear before I begin the transition:
1. Are there (text) guides showing differences/changes between OMV plugins and Docker? I want to know where the files from /etc/.config/ should be moved to

2. Are there good beginners guides for Docker, preferably with pictures/text?

3. I understand that generally it is ok to run Docker instances within a VM. But specifically to OMV, are there known issues arising from this?

4. Are there any performance impacts that I should be aware of?

5. Should I instead run these programs with Docker under Windows for now until I can run OVM5 with baremetal instead of VirtualBox?

6. What else should I take note of when making the transition?

Thanks!

Quote from SaSsL77

Hi,

i`m sorry, I didn`t want to be rude. I was just wondering why I schould try it and they didn't want to try it for themselves.

all the best and no offense

It's not that I don't want to try, it's that I can't try it right now (am still making more space in my HDD so that I can spin up a test VM).

In fact, not everyone has the time/skill to test things out and some may simply want to confirm before testing so that they know if they are the ones making mistakes or if it turns out to be a known issue that needs to be fixed at the code level.

Making assumptions about others and phrasing things like this isn't going to earn you brownie points anywhere

Quote from johnvick

Yes I tried this when moving from OMV 4 to 5 and it works.

Thanks! When you say you moved from OMV 4 to 5, is that an upgrade install over an exisiting OMV setup, or is that a new install?

Quote from SaSsL77

Code

Hi,

I think there is a variable in the file /etc/default/openmediavault named OMV_SHAREDFOLDERS_DIR_ENABLED which has to be set to = "YES" to activate the sharedfolders.

greetings

That's the flag I was referring to and I do not want to use that as it seems that there are very good reasons why this feature is deprecated

Quote from Adoby

Yes, I think it is possible. But I haven't tested it yet.

Why don't you test it and see if it works? Please report any findings back here.

I just want to know if my theory is sound before I go test it; no sense in testing out something if its theory is wrong.

I might take a while though; things are quite hectic recently

Quote from SaSsL77

Hi,

i don't know why I have to test it for you and you can`t try it out by yourself, but I did it once and it works.

greetings

Thanks for the confirmation. Though you may want to rephrase things a little lest you come across as being hostile/rude

Hi, I am using Duplicati and Transmission with my OMV 4.x setup. I understand that in OMV 5.x most plugins will be deprecated and therefore will need to be run via Docker

Can I just install both Duplicati and Transmission directly into OMV 5.x like how you would install programs into a Debian setup?

I am trying to avoid Docker as I want to prevent nested virtualisation if possible; this OMV setup is actually a VM in my Windows machine (I decided to stick with one physical machine for now)

Edit: Technically speaking, I can install both of them into Windows, but this will mean having to re-backup all of my data (about 10 TB at least) as you cannot backup files written in Windows directory style into Linux directory style and vice versa, and Transmission for Windows is still in early preview, which means I will need to migrate to Qbittorent by hand

Hi, I understand that the /sharedfolders/ directory will not be available for new installations of OMV 5.x (unless I turn on the flag which I am trying to avoid).

Can I use symlinks instead? Idea is to turn that directory into a symlink to the actual /srv/ directories

Quote from tkaiser

In my opinion yes.

Thanks, let me see how this install goes!

Quote from tkaiser

Yep, 'seems' it worked. If problems occur you realize them way too late.

It's really that easy:

• open files are a problem (you can't save them appropriately)
• the time such a 'backup' needs is a problem (if it takes more than 0.1 seconds inconsistencies might be the result)
• applications that are not aware that such a 'live backup' is about to be started have no chance to save their data/environment in a consistent state

For such a 'live backup' you need to be able to freeze the filesystem (impossible without snapshots) and you also need a mechanism how to tell applications to save their data in consistent state prior to the live cloning happening.

To get the idea just do a web search for Microsoft's shadow copy service. Something like this (and especially applications that agree on the OS mechanism to need app data in a consistent state) is needed. Otherwise results are unpredictable and usually you realize that something went wrong way too late.

There's a reason filesystems that have been invented in this century provide features like snapshots. Since this is essential to 'freeze' the filesystem in a consistent state which is most basic requirement to do a 'live' copy/backup/clone. And still the problem is how you get applications to reliebably save their data (open files -- think about databases).

Simple excercise: check open files manually:

Code

lsof / | awk 'NR==1 || $4~/[0-9][uw]/' | grep -v "^COMMAND"

If important files are amongst the list expect a live 'backup' failing.

Display More

Hmm, good point, I missed out the part about applications being open during the live backup; a simple OMV setup may be ok with live backups while a more complicated one with many plugins open at once will be tougher to manage right?

I guess unless there is a way to run OMV on a ZFS system like how pfSense allows you to install it on a ZFS filesystem during install, it is still better to simply schedule downtime and do things the "hard" way (i.e. manual backups and testing of such backups)?

Thanks! Surprising that there is no hard and fast rule about backing up a live system.

Maybe a middle ground is to do both to cover more variety of scenarios?

Quote from macom

For your OS?16GB should be enough. Depends of course on your use case. For example if you use Plex and place the database on the OS drive you might run out of space if you have a large library. But this can be avoided by placing the database on another drive.
Docker container also need some considerable amount of space.
Any way 16GB should be a good starting point.

Why do you want to do this?

Yes, this pendrive is mainly for OMV OS and plugins. For Plex database (if I am ever using it), Docker and VMs, they will be on a separate HDD

I want to have logs on the HDD just in case the pendrive breaks down and I need to read the logs to show me what else has gone wrong

Quote from tkaiser

Most important task before putting anything on flash storage: test the device: f3 h2testw site:forum.openmediavault.org

The larger the pendrive, the later it will wear out. But if you use flashmemory plugin this shouldn't be an issue. OMV without any plugins that want to write to the rootfs is fine with well below 4 GB.

I personally run all small servers from pendrives or better SD cards (on the latter I can TRIM from time to time which is really great for various reasons) and do some 'backups' from time by powering the device down and then cloning the boot media (in my case not to another media but to my backup server that utilizes btrfs and snapshots so at the filesystem layer I always create a new and large image but in reality due to transparent filesystem compression and snapshots I get compressed and incremental backups. TL;DR: use another pendrive and clone the first from time to time, this way you can also easily test upgrades)

Good idea, thanks! As for imaging the pendrive, is there a way to do it as the OMV NAS operates? Or do I need to schedule downtime and do it using Clonzilla (or similar software)?

After some thought and playing around with my pfSense rig by using a thumbdrive on it in lieu of a HDD, I am thinking of doing the same to my OMV NAS when I upgrade from 3.x to 4.x.

I am planning to:
1. Do a fresh install, install it onto a 16GB stick that I have lying around
2. Get omv-extras and then flashmemory plugin
3. Set cron jobs to write logs to a HDD (which will contain files for other functions of the NAS like VMs)
4. Get omv backup plugin to write backup of the OMV OS to the HDD too

I am wondering the following:
1. Is this a viable setup? (As in, does this even make sense?)
2. Should I consider using another 16GB stick too? (So that I will be using 2 sticks instead of just one; I am even wondering about RAIDing them...)
3. How do I restore the OMV OS and logs in case things happen? (I saw the backup plugin in OMV 3 too, but am unsure how to restore from its backup)
4. What guides should I consult to help me understand what I can do better?
5. How much storage space do I need? (Need to know as I need to figure out if I really have to buy a 32GB stick for this instead of just reusing the 16GB sticks I have)

Thanks!

Quote from ryecoaaron

web servers are generally low load. So, I would think you could run these on your OS disk.

I have a couple of servers running on USB drives. No issues here.

Thanks, let me think about the USB drives. May go with an USB enclosure holding onto a HDD for best of both worlds

Quote from ryecoaaron

Depends on what you use OMV for and what the virtualbox guest(s) are doing.

I am using OMV as my NAS (SnapRAID or ZFS, file server (i.e. SMB), NextCloud, VirtualBox, Plex (still deciding))

VirtualBox guests are going to be development servers for my websites (and maybe NextCloud too?)

I am going to try using one HDD for OMV boot and these VMs first and then play by ear; it seems that it is not a good idea in general to run OSes on USB drives

Quote from ryecoaaron

You could setup a scheduled job to run the folder2ram -syncall tag to write the contents in ram to files.

Hmm sounds like a good idea but as a side question, will there be any performance hit if my OMV boot disk is also used for VirtualBox?

Idea is that if there is no performance hit, I will prefer to just stick with what I am doing right now, which is to simply partition one HDD for OMV boot and data usage instead of using an USB for OMV boot only (all these things I did in this thread are just for testing before I make the jump to OMV4)

I tried the RAM removal idea, it works!

I left only one stick of 4GB RAM and could get OMV4 to install onto the 8GB USB stick

I may not use it after all though since I realised that using the flashmemory plugin meant that logs would be in RAM until restart/shutdown; this may make diagnosis of problems harder down the road

Quote from donh

Not sure what hardware you are on. Old Dell and maybe some other servers had an "os install" setting in the bios. This showed the os install only 256MB of ram. Never had to use it but it drove me crazy once. Always wondered why they would do that but maybe you found out why. Anyway maybe you could remove as much ram as you can.

Or do a debian minimal install and partition the diskd the way you want. Then install omv.

I an using consumer grade Z77/Z68 boards that have no such issues during OMV3 so I dont think that was the cause of this problem

I will try the RAM removal idea first then

Tested with a DVD and an USB BD drive, it worked with a SATA 1TB HDD and the aforementioned 64GB USB 3 thumbdrive (which I noticed is identified as a pSSD in Parted Magic). Same error message is seen for the 8 GB and 16 GB thumbdrives.

I noticed it indeed creates a swap-file partition that is as big as the amount of RAM on the system and that on the HDD, as much as 16GB is used for OMV files alone while only 1.5 GB is used on the thumbdrive.

I can't workaround for the smaller thumbdrives though; not even transferring their files or copying the partitions from known working installations.

Are all these intended as design?

Hi I am having same issue too, tried installing on a 8GB USB 2.0 thumbdrive and 64GB USB 3.0 thumbdrive from a 8GB USB 2.0 thumbdrive or a 16GB USB 3.0 thumbdrive of various brands

Sounds like either installing to a SSD/HDD or doing the Netinst method may be the only workaround.

Let me see if I can get the Netinst method to work since I have to install OMV onto a thumbdrive as I have no more HDDs left

Alternatively I can try the DVD method; apparently the installer USB thinks that it is a DVD based on the options I see if you exit some parts of the installer but not entirely (I am seeing something about ejecting the DVD...?!)

Now if only I can find a spare DVD in the first place!

Hi, I can confirm this works (just swapped my motherboard and NIC). This is so as within OMV (its database I think?) each HDD's identity (e.g. sda, sdb...) are tied to each HDD's serial number. Same goes for NICs if I am not wrong.

As long you do not reinstall OMV (i.e. format the disk drive containing OMV), these pairings will be consistent regardless of motherboard used.

You still need to run omv-firstaid and then the commands to register the new NIC (and erase all previously used NICs) if using a new one as the OMV installation does not have any pairing related to the new NIC, making it inaccessible from other computers to administrate it

Quote from ryecoaaron

That is a good sign.

As mentioned before, if the filesystem didn't unmount properly (process not stopping) when you rebooted, it is possible.

Thanks, I hope this does not happen again (and if it does I at least know how to fix it.... I think?)

I went ahead with the long term and fsck -f

Everything passed so far, which means there are no problem?

Still puzzled on why this occurred in the first place