Just a quick response: The "regular" / manual restore without the scrip has worked flawlessly for me. It's the most convenient way in order to get OMV up and running with the latest config changes. I do have clones of the sdcard though but as I am doing this procedure always on a different machine I would have to shutdown the NAS what I am trying to avoid. Really nice work.
Maybe I will also have a look into the script later on but for now it is as easy as it need to be for my needs 
Well, putting the performance aspect aside: Do you need the encryption? That's the only question you have to answer regardless of the performance. If you need it, encrypt the data drives. If not, don't.
My use case: I have the NAS at the office and I do encrypt my drives as it contains also sensitive data that should not swirl around once the machine maybe got stolen and the harddrives are read / sold / whatever.
I can live with the performance loss but would also think it is not huge. Maybe different once another nas hardware will get in here, but hopefully not as I will also encrypt the drives
Thanks for clearing that out.
What kernel did you hold? If it was a backports kernel, then you need to hold two packages - the versioned kernel package and the linux-image-amd-64 package.
I put these packages on hold:
armbian-bsp-cli-helios64
armbian-firmware
linux-dtb-current-rockchip64
linux-image-current-rockchip64
linux-u-boot-helios64-current
Just checked this morning within the OMV gui and also the former kernel updates vanished - which is great. Ran the most current update via cli and indeed did not touch kernel or firmware.
So that's great news, bit strange though that it did upgrade yesterday via the cli... Anyhow: works 
Okay. Does that also include the omv-upgrade command executed via cli? Because I did hold the kernel (showhold shows the entries accordingly) but somehow the machine did update to the latest kernel.
Sorry for these noob questions but I thought: once I mark them hold that either way it is impossible to update to the latest firmware and kernel.
Old thread, I know, but I was running into a similar "issue": when putting the kernel and firmware on hold in order to prevent future updates OMV tells me nontheless that there are indeed updates. As I am no longer able to tick which update I wanna get within the GUI I suppose I have to do future updates manually over the cli in order to prevent OMV to also install the kernel updates, right?
Or is there a possibility to still use the GUI for updates but current firmware and kernel remain untouched?!
Just read and follow the post above yours
Yes, I found the docs of course. I can list all the variables and the current values, but not the original value... Or maybe I am just blind...
Question: Is there a list where all the environmental variables are shown with its original values?
I have set different variables for samba shares and I try to revert some of them but did not pay attention what the original value was. Any hints where I can find that?
You might wanna have a look at this thread. The solution is there:
Probably refer to this thread that docker is not properly running after the update:
The current workaround is posted there...
I use a VPN server running on my router and a VPN client on my remote PCs and phones.
I do the same. I once also tried it with a domain, Cloudflare and a reverse proxy but I like the VPN solution a lot better as it requires a little less effort to me.
Maybe i find a way around this someday or never.
What about starting the mergerfs pool manually once the system is booted up? That's what I do, too instead of relying on the mergerfs plugin that has caused several reboots on start because it could not find a valid filesystem (hdd are encrypted at this time).
For me it was the only way to get my system running (and booting) solidly. With the minor flaw that I have to start the decryption process and the mergerfs pool manually. As I am maybe starting the NAS 2 times a month it has become a routinely non-issue.
On my helios64 I had similar issues. At the end it was a faulty battery that interfered with the shutdown process. Since then I am running the nas without any UPS and it runs flawlessly again.
As I am accessing also the same shares with both protocols it's kind of easy to rename the AFP shares through the config-file in order to make it clearer for both admins and regular users
Thanks I will do memtest this morning, turns out it's not a PSU issue
One more thing: Do you have a USP Battery set up? I had a lot of random reboots recently and it turned out that the USP battery was the culprit. Once I got rid of it everything worked as expected again.
Any particular reason for using AFP? Even Apple recommends SMB...
For me it is way faster than SMB in combination with my setups (helios64 and HC1), especially when it comes to transfer a lot of small files.
There are several threads here on how to adjust the SMB settings accordingly but I always got back to AFP for getting more speed. But, of course, it might be completely different on your setup so I think everyone has to do a little bit of trial and error in order find the right protocol.
Yes, above method works flawlessly (since quite a while ;))
Mine have been sitting unplugged for months. The 2.5GBe port was horribly unstable.
Interesting. I have no issues neither with 1GBs nor 2.5GBs ports... I do believe I got one of the last shipments (but I am unaware if they changed anything with these ports btw).
Yep, I would also say you have to consult the kobol-forum. I remember some threads about the fan issue which I never had. Here is one thread for example (https://forum.armbian.com/topi…3-fan-not-working-at-all/) there might be others, too.
ryecoaaron I do hope it's gonna be a sloooooooow death although it is inevitable as Kobol pulled the plug. But I love that unit very much and I do believe that I will have fun with it for another long period.
Apple owns samba. You would think it would be better. Did you ever try nfs?
Yep, I also tried nfs which was about the same as samba speedwise... For the moment I am happy as I don't want to do trial an error with modifying samba settings. To me it is just strange that it is such a huge difference - at least in my setup.
Very old thread, but I just wanted to say how pleased I am to went back from SMB to AFP protocol. It might be really deprecated anytime soon, but meanwhile I am so happy with fast access to me NAS (Helios64). It's double the speed that I get with OMV6 and Samba shares. I just don't get it why netatalk is being abandoned for a protocol that does not work entirely well in the macOS universe...
