There have been many issues with desktop environments installed parallel to OMV. Both are controlling system files and that can cause issues. Therefore the use of desktop environments is being prevented.
Guess I can sacrifice the desktop environment.
Didn't have the resources for a virtual environment before but now with the upgrade should be feasible.
May I ask what is the best method to be sure I remove everything that can trouble OMV?
I have an unexpected issue...
When I run omv-release-upgrade it's stopping with:
Upgrading system to 6.0 (Shaitan) ...
This system is running a desktop environment! This setup is not supported.
How can I skip this check?
To be precise: I know how I can skip it but I wonder if there's a "safe" way or will cause troubles afterwards
But I would not overthink this.
You are right I'm already overthinking it 
And last time I've read about Proxmox here was too many years ago, ouch.
I see now zfs module is available also without Proxmox and in ryecoaaron signature that he's using 5.15 Proxmox.
Lots of fun ahead!
This will upgrade both, Debian from 10 to 11 and OMV from 5 to 6
Awesome thanks!
I have another question; is there a newer Proxmox experimental kernel for Bullseye?
I'm currently running Proxmox 5.11 and I see in that thread that after the upgrade versions 5.15 is offered.
Not sure which one to pick... right now I don't have ZFS volumes but I was planning to.
Is there any other obvious advantage with the Proxmox kernel?
I'm asking because the CPU is an AMD 5600G.
Long term I'd like to go to 5.17/5.18 to use the amd-pstate module.
Not sure how fast are the Proxmox releases, if they'll soon be there or in years.
I see the unstable branch is at 5.16 so the vanilla kernel branch is getting close already.
Now that seems I've successfully upgraded to Debian 10 / OMV 5, I want to complete the upgrade and go to Debian 11 / OMV 6.
Note: my setup is a Debian server with OMV on top.
From my understanding the procedure is to upgrade first to Bullseye and then follow these steps:
So my questions are:
Thanks!
If you're not using compose (you might be able to fix them with docker-run, not sure), it might be a slightly bigger pain depending on how many containers you have, etc...
I have Portainer, should be fairly easy
That's why it looks like youv'e lost everything on your containers. You didn't really lose it, container is just just looking in the wrong place for it's folders. When you restarted docker, it basically created a bunch of default directories at the old location (ie, /sharedfolder/..) and since those were blank before docker started.. it looks like the container is brand new again and needs to be setup.
That's the weird issue, probably hit a corner case last time....
My /sharedfolders/ mounts were working and are working as well now.
No empty directories, they are all still correctly mapped to the volumes in /srv.
Last time I could see the files in /sharedfolder/config mount, I could even create a file from inside the container and see it on the host.
But somehow all the containers wiped out the configuration and runtime files.
Including a big influx database. All the files which were not in use, like an old db backup from the influx upgrade, still there untouched.
Not sure why, I'm not a big expert of Docker and neither a big fan...
I'll get rid of the /sharedfolder stuff as soon as possible 
Do I have to take care of this change somewhere else that you know of?
Guess Docker is the only component outside OMV where I've used /sharefolders but maybe I'm missing something obvious.
Was OMV still using /sharedfolders/share_name (I'm thinking it did, but can't remember back that far). Is that the path you put in your docker contianers?
Yes, exactly /sharedfolders/config
If that's the case, that would be the issue.. OMV 5 does not use /sharedfolders anymore for it's share paths and it's likely when you started docker in OMV 5, it just created a bunch of empty paths under /sharedfolders.
What???
Damn, I didn't know about this change.
I don't see any difference right now with OMV 5 about /sharedfolders structure and "Shared Folders" in the UI.
All is working so far, but...I have a new array and I see that the new media folder is not mapped in /sharedfolders
I guess I have to change all containers mounts ASAP...
Your containers volume paths likely need adjusted to point at the UUID location of the shares..
This is also worrying me... all my previous mounts on /srv are with dev-disk-by-label-.
Only the new array is mounted with dev-disk-by-uuid-.
Is this going to be a problem? Could be at some point they will get mounted with the uuid or they'll stick with the label?
Thanks a lot for you help guys.
So far the new upgrade attempt went well.
(I would agree it's going to be easier to fresh install 6 however)
I agree as well but this is a Debian server with OMV on top.
There's a universe of stuff besides OMV... monitoring, development, etc...
Wouldn't say I'd prefer to be evirated instead but for a short glimpse I'd consider it
Thanks for the tips.
I have saved the configurations as that was what I expected to loose.
But I wouldn't have ever thought such about such a massive wipe of the config directory.
Unfortunately it's something I didn't set to backup automatically and I didn't saved them before starting the upgrade...
Now I'm restoring form the last backup and will attempt again.
Hopefully will take less than before now.
Is there a real backup and restore tool for Docker containers?
I have used this procedure to take backups but of course in this case didn't save me cause the host folders were wiped:
https://docs.docker.com/desktop/backup-and-restore/
Is there something better?
I really think an OMV4-OMV5 and then OMV5-OMV6 upgrade is a long road and possibly full of problems, especially the OMV4-OMV5 step.
Unless you have too many custom configurations, I think it would be easier to do a fresh install of OMV6 and reconfigure.
You nailed it down: "Unless you have too many custom configurations"
The fact that I'm willing to spend days over and over to upgrade it says it all...
That user should be in the docker group, and also have write permissions on the folders they need to access, or be in a group with access to those folders. Make sure of this.
Yes it's in the docker group and of course it has write permissions, enough to wipe out everything 
with su?
If you mean to type su in the CLI from the dockerperson user, it is normal that you can do a few actions not normally allowed.
That user should be in the docker group, and also have write permissions on the folders they need to access, or be in a group with access to those folders. Make sure of this.
su - dockerperson form the host
Since the upgrade I've also the config folders filling up with these empty folders:
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 14:10 custom-services.d.p2wbF_V2
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 14:10 custom-cont-init.d.p2wbF_V2
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 14:53 custom-services.d.Zzg_m4Em
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 14:53 custom-cont-init.d.Zzg_m4Em
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 15:59 custom-services.d.yO_cy1Vc
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 15:59 custom-cont-init.d.yO_cy1Vc
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 16:07 custom-services.d.UlwaM31x
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 16:07 custom-cont-init.d.UlwaM31x
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 16:29 custom-services.d.UqaWv9ce
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 16:29 custom-cont-init.d.UqaWv9ce
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 16:44 custom-cont-init.d.HYY-trQP
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 16:44 custom-services.d.HYY-trQP
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 20:11 custom-services.d
drwxr-xr-x 2 dockerperson users 4.0K Aug 11 20:11 custom-cont-init.d
I'm checking the permissions one by one and there's no issue with the config folder.
But somehow installing Portainer with the OMV GUI made all the containers destroy everything... databases, configuration files, all wiped out.
At this point I'll have to go back to the last backup and spend another time a few days on the upgrade, really sick.
But how this could happen?
How can I avoid that it does it again?
That would have been easy....
It was working perfectly fine, no changes in permissions.
With su under dockerperson I can cd and cat the config folders of the containers.
I'm the process of upgrading from OMV 4 to OMV 6 and so far made it to OMV 5.
Almost everything went well except the infinite loading loop due to unionfs.
Then the nightmare came in when I've installed Portainer from the UI and it did something to the Docker installation.
All my containers were working fine.
They have bind mount points on the local filesystem with UID 1001 and GUID 100 (dockerperson:users).
The images are all supporting the UID/GID/GUID environments and were working perfectly fine.
Now not a single one can see the host filesystem.
I can't find any reason why and there's no log anywhere that I know of that could help me troubleshoot.
Any idea what to look for?
Hi all,
I've decided to spend a lot of money and upgrade my scrap metal/experimental omv build to something more than decent.
Still in the process of building and then I'll move to the upgrade since I'm using a Debian 9 standalone server install with omv4 on top.
Tried for fun the upgrade script and it failed miserably
I'll definitely need some help in the future but that's for another thread...
What I'm currently suffering with is to find a good 2.5G or 10G NIC.
The board is an ASRock X570M Pro4 and comes with a Realtek 1G r8125.
I have available a PCIe x4 (x16 electrical) slot for the NIC.
In my previous build, with a primary Intel 1G NIC, I was using a USB 2.5G Realtek NIC r8152.
Working quite well as dedicated for Samba traffic.
The only problem with this NIC is the driver which is bugged in all latest versions and spamming syslog with one or more "connected" message every second.
Also why not using a PCIe adapter instead of USB?
On top with the new build I started having interface binding issues with Samba; it was randomly starting to serve on the 1G NIC instead of the 2.5G.
Funny thing is that my PC was connected to the 2.5G NIC but the traffic was going through the other NIC.
Realtek drivers are really one of the most horrible things in history...
Thought that maybe using a PCIe 2.5GB r8125 NIC would make things better but I was so wrong.
Not that I had many options for a quick and cheap buy.
Anyway I can send it back in 30 days.
The PCIe NIC it's just garbage.
Not only I have the same Samba issue but it's even worse.
Even without any IP assignment the 1G NIC would serve Samba traffic and there was no way to set it properly.
Not just a random thing anymore.
Plus every 5 to 20 seconds the bandwidth is dropping down to 0 or 1000Mbps.
Quite horrible.
Maybe is this China brand sample faulty but I'd really like to avoid Realtek if possible,
Was going to buy an i225-V but then I've found out it's poorly supported and only with Debian 11.
So my question is if you can give me an advice for a decent 2.5G or 10G NIC that works with Debian (9)/10/11 in a 100/200€ range max.
What do you suggest?
I have ordered a QNAP QXG-5G1T-111C and it should arrive tomorrow.
It's a Marvell Aquantia AQC-111 based card, 2.5/5G speeds and only 75€.
Seems to be properly supported and also on Debian 9:
https://github.com/Aquantia/AQtion/blob/master/README.txt
Have installed already the latest 2.5.5 driver from the Marvell website with dkms.
If you have experience with this card/chip let me know.
Update:
Got the QNAP card and I like it.
Found out the Realtek card wasn't faulty.
Drove me crazy for a while but finally found that an old Trendnet switch was creating havoc in the network.
Luckily I had already a replacement ready.
My main Switch is a QNAP 2.5G so the new card plays really well with it.
Samba performances are great, sensibly better than the Realtek.
So far so good, I'd recommend this card at this price, good deal.
Especially since it does support 5G, there's some room for future improvements.
I'm limited by 2.5G Moca adapters anyway but you never know maybe some day they'll come out with a 5G.
Sorry for double post I got an errorat submit and didn't realized it was posted already
Cheers
Hi all,
I have OMV installed on a Debian 9 server.
It's been very smooth and I had very few issues, much less than expected considering is not the full image.
Since the start I had randomly this issue with monit error at Apply config but I was able to recover restarting the monit service.
Once or twice I had to restart the whole server but I always postponed to investigate being so sporadic.
Now it's permanent and while the config is properly applied and saved, it's quite annoying to have the banner at all times.
Error #0:
OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; monit monitor collectd 2>&1' with exit code '1': Error receiving data -- Resource temporarily unavailable in /usr/share/php/openmediavault/system/process.inc:182
Stack trace:
#0 /usr/share/php/openmediavault/system/monit.inc(115): OMV\System\Process->execute()
#1 /usr/share/php/openmediavault/system/monit.inc(82): OMV\System\Monit->action('monitor', false)
#2 /usr/share/openmediavault/engined/module/collectd.inc(81): OMV\System\Monit->monitor()
#3 /usr/share/openmediavault/engined/rpc/config.inc(194): OMVModuleCollectd->startService()
#4 [internal function]: OMVRpcServiceConfig->applyChanges(Array, Array)
#5 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
#6 /usr/share/php/openmediavault/rpc/serviceabstract.inc(149): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array)
#7 /usr/share/php/openmediavault/rpc/serviceabstract.inc(565): OMV\Rpc\ServiceAbstract->OMV\Rpc\{closure}('/tmp/bgstatusdn...', '/tmp/bgoutputC8...')
#8 /usr/share/php/openmediavault/rpc/serviceabstract.inc(159): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
#9 /usr/share/openmediavault/engined/rpc/config.inc(213): OMV\Rpc\ServiceAbstract->callMethodBg('applyChanges', Array, Array)
#10 [internal function]: OMVRpcServiceConfig->applyChangesBg(Array, Array)
#11 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
#12 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('applyChangesBg', Array, Array)
#13 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('Config', 'applyChangesBg', Array, Array, 1)
#14 {main}Could be that I've updated monit at some point and it doesn't work well with OMV 4.1.12.
Not entirely sure but I suspect it became permanent once I recently upgraded OMV from 4.1.9 to 4.1.12.
This is the monit version:
monit/stable,stable,now 1:5.20.0-6 amd64 [installed,automatic]
The server is using Proxmox kernel:
Linux server 4.15.18-7-pve #1 SMP PVE 4.15.18-26 (Thu, 04 Oct 2018 11:03:06 +0200) x86_64 GNU/Linux
Any help would be appreciated 
Cheers