I have had 3 show stopping bugs/glitches/bad updates
Which are? This docker issue is not an OMV issue.
In light of this recent loss of my containers
Why did you lose your containers? If you apply one of the fixes and reboot, your containers should just come back.
ZFS seems pretty questionable on OMV
Why? I don't have issues.
that was one of the first issues I had right after I installed it was that the packages couldn't install because of kernel header issues or something similar, I don't remember exactly, and so I had to install the Proxmox kernel in order to fix the issue. So that alone should have been a red flag that ZFS is not exactly stable on the Debian base or some other issue was going on.
That is because Debian doesn't fully support zfs. Compiling kernel modules is not easy. The proxmox kernel does support it since it is the ubuntu kernel. This is a very minor issue in my opinion.
In the server world this would be completely unacceptable.
I work in that world. OMV is not meant to be an enterprise product. We have two devs (one for omv and one for plugins). That said, I run into more "showstopping" issues with VMware products at work than I ever have with OMV.
Please don't take this post as trolling or anything like that because it's not the intent. Perhaps quality control needs improved or something done to improve the reliability of OMV.
No offense but it is pure trolling. Pointing out issues is one thing but most of your comments are just the OMV has issues and other things just work. If quality control needs to be improved, then other people need to help. We have almost NO help other than people just whining that things are broken.
If we don't tell the devs then how will they ever know.
You haven't told us anything other than you are unhappy.
I really look forward to responses so that I can make a decision going forward.
You don't need someone else's opinion. OMV is obviously not working for you. I've run OMV on many boxes and don't have any problems. I recommend using webmin since it does "everything" that OMV does.
But unfortunately the ones you have are making questionable choices with key features.
You say it isn't personal but then you say things like this, it is basically calling me out. You are only having problems with omv-extras features (docker, zfs). Don't use my shitty code if it is causing you problems. omv-extras is optional.
Business is business, this isn't personal in any way.
If this was a business, I would get paid. I am volunteering to do this in my free time!
People pointing out bugs and issues are fully expected when developing software. Sorry I am not a developer and that shouldn't exclude me from voicing a concern of stability or bugs. Do you expect all of the other forum users to contribute to code in order to be allowed to post here as well?
The docker issue was not caused by my code. I get their releases the same time you do. How is this preventable? I do expect users to post bugs. You are not doing that. You are just asking if OMV sucks or not.
You're reasoning is that since you don't have any issues that nobody else can possibly have any at all.
I didn't say that. I was just telling you I don't have problems. Isn't that you want to hear with your poll?
That's just not the way software development and bug reporting works for most open source projects. Most open source projects are fully open to suggestions, bug reports, comments, and questions.
Thank you for the dev lesson. I think you need to read the forum and github issues pages a bit more before you say I'm doing it all wrong.
Personally it took me many years to be able to not take things personally. Please don't take me personally. I don't intend any bad feelings and this thread says nothing about the integrity and good will of you or the devs or anyone.
Sorry, I do take it personally because I work on OMV as a hobby. I spend a lot of time on it. This isn't a job and don't even get enough donations to cover my costs.
I will give you one point of advice. In the "server" world, you test updates on a non-prod server before rolling them out to a production server. If your server is so important that you can't have any of these issues, you need to test updates.
What shall i say after reading these posts..... nothing.... except that i get more and more the impression that people set the bar from commercial products to open source and forget that in most cases these are shouldered by people in their spare time for free.
LinuxGuy2020 I can't answer the poll as I don't have OMV in production at the moment. As far as the zfs plugin is concerned it doesn't cover every aspect of zfs and some actions need, or are more convenient to do at the CLI. I've no idea of what previous use of zfs you have made but there have been plenty of posts advising people to first install and boot into the pve kernel and then remove any backports kernels before installing the zfs plugin. This totally avoids any issues with debian dkms etc. The zfs filesystem is stable on debian, https://wiki.debian.org/ZFS, but no one should blindly apply kernel/zfs updates without first checking message boards for potential problems. Automatic updates can have unwanted results when there is no simple rollback mechanism.
A fix for the recent docker issue was quickly put on the forum. For the few bugs I've found while testing OMV, there's always been a timely response from ryecoaaron.
If you use proxmox you can set up a "fileserver" in a lxc container using a "turnkey" image, or do it by hand, but you will not read a proxmox dev advising the use of docker in anything but a virtual machine.
If you really want bugs/reliability problems then be all means install TrueNAS SCALE, in which by the way there will be no docker at all by this October's SCALE release. TrueNAS CORE is solid, but you'd have to wrestle with FreeBSD jails for apps ( their plugins are no longer useable), or run docker in a bhyve virtual machine with the additional overheads and complexity.
I really wouldn't be so quick to dismiss OMV6. It has a lot of flexibilty, but of course it can be abused and people do and will shoot themselves in the foot. During my testing it's never crashed unless I did something stupid.
ZFS seems pretty questionable on OMV and that was one of the first issues I had right after I installed it was that the packages couldn't install because of kernel header issues or something similar, I don't remember exactly, and so I had to install the Proxmox kernel in order to fix the issue.
I've used ZFS, with OMV, on multiple servers for years. That includes standard kernels, backports kernels and proxmox kernels. The only issue I had was with kernel upgrades, when using backports kernels. (ZOL project doesn't keep up with the latest backports kernel releases.) I did have an issue, one time, when building the headers for a standard kernel. I suspect the actual problem was caused by an internet download issue at that time.
core. Literally installing vanilla Debian with Webmin and we can get the same functionality as OMV with a GUI.
I can surmise, just by reading this passage, that you haven't actually tried setting up a working server with Webmin. Is it doable? Yes. Will you have the same functionality? No. You see, I tried it. By the time you sort out how to get the same functionality (that's a MASSIVE time investment BTW), you'll be on the command line in many instances. There is no way you're going to get the flexibility with Webmin that you'll have in OMV's GUI and with OMV's plugins.
However I also had watchtower running once a day to update all the containers and I questioned if that broke things but it sounds like packe updates are what caused the issue. I mean we can blame the Debian base on updates breaking things but I have used Debian long enough to know that bugs like that are completely unacceptable.
Here's the real issue, and it lands in your court.
When you alter the state of the boot drive, from that of a plain NAS server; creating a media server / downloader / home alarm system / etc., etc., using Dockers or direct installed packages you are:
1. Increasing the complexity of the boot drive, with every add-on package or Docker added, to were a rebuild is no longer a 15 to 20 minute process.
2. This creates a single point of failure that's difficult to recover from in a short period of time. With the configuration processes of adding and configuring Dockers alone, it may take several hours to recover from a boot drive problem, regardless of whether the problem is with a package or drive failure.
3. When the above comes into play, when complexity begins to soar, what is the common sense solution? BACKUP...
So, did you backup your boot drive? NO. The answer is NO. If you had backup, you wouldn't have written the diatribe above.
________________________________________________
People that work on this project go out of their way to write software that is usable, reliable and flexible "if" users have reasonable computer skills AND/OR if they are at least willing to read. -> User Guide (and more specifically) -> Backup.
I'm sad and angry all at the same time because I want OMV to work for me but I can't trust it anymore. /----/
Please don't take this post as trolling or anything like that because it's not the intent.
(Keeping in mind that I've had Windows updates that have gone south...)
If you don't trust OMV and you won't take common sense precautions, like backing up your boot drive, then maybe you should move on.
One thing that everyone who supports this project knows is that it's impossible to support all users, in the way they'd like to be supported. It's simply not possible to be all things to all users.
Note that I'm not trolling you when I say this but, there is no shortage of critics. What we do have a shortage of is, those who will "support".
I work in that world. OMV is not meant to be an enterprise product. We have two devs (one for omv and one for plugins). That said, I run into more "showstopping" issues with VMware products at work than I ever have with OMV.
i literally started using WSL because of this at work 
What shall i say after reading these posts..... nothing.... except that i get more and more the impression that people set the bar from commercial products to open source and forget that in most cases these are shouldered by people in their spare time for free.
this is a problem i see all the time with FOSS, i also work in the "server" world .. first off, i salute you Devs.. the tireless work you do to make OMV a usable, viable simple product is amazing
mostly i see this tho. : "i use it and expect it to be enterprise grade, however i will not pay or donate or contribute to the product in any way except to slag it off when i have problems, its also free to troubleshoot from an active community that i also do not pay for or contribute to"
i used OMV on and off for years, i just switched my install back on after nearly a year sitting in the cupboard after moving house, and it booted, ran updates and is A-OK.. i then decided to ditch my spinning disks in a raid config for a single SSD, i used the forums to find all the info i needed and didnt need to ask a single question, then i migrated my OMV install from a USB stick to an M2 SSD .. all using the forum and without asking a single question, the docker issue, i googled it, saw it elsewhere mentioned, made an informed decision it wasnt omv related and decided to install app armour any way.. docker is transient in nature so as long as the data is "somewhere" it will always boot back up in the same state it was even if you uninstall docker.. no biggie.. if you are using OMV for mission critical then i suggest getting an enterprise app or hardware and pay the money for the support if you require that and cant troubleshoot minor / annoying (linux) issues
But you'll miss out on the joy of getting it working by finding out the answers and making it work by tinkering which i think is major draw of linux based applications like OMV .. if you dont like "getting your hands dirty" get windows server
I've been running OMV for about 6 months and within that time frame I have had 3 show stopping bugs/glitches/bad updates.
Brand new here, but been in software forever and a day [I registered dot com #43, how's that? 
]
I just have one comment on this perspective. Please please learn ASAP: ALL Software Has Bugs.
To operate on the assumption that my system, especially my Important System(s), will properly survive an update... is unwise.
Anybody who has never experienced a "reliability problem" with any software, simply hasn't used it enough, or deeply enough, to discover the existing bugs.
Here's a corollary: any system connected in some way to the Internet can be breached. There's no such thing as a perfectly secure system. I have interesting friends in that biz who could prove it to you, without breaking any laws. Their metric: how long does it take to break in w/o you finding out, not "can we break in?"
Act accordingly.
I apologize for not being professional. If you find bugs, file github issues. I try to keep chit chat to a minimum in github issues and focus on the problem. But a forum is supposed to be like "water cooler" talk in my opinion. To be in open source and deal with the extreme lack of help, you have to be passionate about what you are doing as motivation. That will trigger reactions on the personal level around the "water cooler".
mostly i see this tho. : "i use it and expect it to be enterprise grade, however i will not pay or donate or contribute to the product in any way except to slag it off when i have problems, its also free to troubleshoot from an active community that i also do not pay for or contribute to"
You're right about this, generally speaking.
But I would point this out; for enterprise software to be truly enterprise grade it requires Enterprise grade Admins. That (Enterprise grade Admins) means 100% OS software and user data backup, ready to go, along with hardware spares on the shelf and/or servers fully replicated and in hot standby. (A minimum of one full replacement item, per hardware platform, or 10% spares.)
I worked as an admin way back in the day with decidedly unreliable software. Did I have a problem? Never. There was nothing that I couldn't dig out of in short order and I do mean "quick". I had full OS and data backups with hardware spares, on the shelf (or in hot standby), all fully tested and ready to go. It wasn't hard at all and it didn't take much time, but the admin must "think it through". The last time to think about backup, spares, etc., is when it's already too late.
I used to laugh as other site admin's sent out horror stories of being down for days while (here's the reality check), they were wasting huge amounts of everyone's productive time on things that were trivial.
I can surmise, just by reading this passage, that you haven't actually tried setting up a working server with Webmin. Is it doable? Yes. Will you have the same functionality? No. You see, I tried it. By the time you sort out how to get the same functionality (that's a MASSIVE time investment BTW), you'll be on the command line in many instances. There is no way you're going to get the flexibility with Webmin that you'll have in OMV's GUI and with OMV's plugins.
I am very new to OMV and Linux in general, but I can vouch for what crashtest said! I tried Webmin before dedicating all resources to OMV. Webmin is really not for newbies, it is much easier to setup complex procedures and customizations on OMV than it is on WebMin and I feel Webmin is definitely not meant for home use.
I'll take managing/fighting with psychotic crazies 12hrs a day vs an ungrateful user base.
I never had any problem. As a matter of fact, one of my users went to an organizational heads meeting where they were all began a major bit-h session about how bad their LAN systems were. He said he sat there, with a smile on his face, and said nothing. When they noticed his smile and silence they asked him, "what's so funny"? He said, "I really don't know what you're talking about." "We've never had these kinds of problems."
Again, it's a matter of "thinking it through". I ordered the right stuff, tested my processes, and had things ready. This was required because I couldn't spend all day messing around with LAN tasks. Keeping the LAN straight, (where it was on autopilot most of the time) gave me more time to devote to other more important things.
____________________________________________
Later, I applied the same principles to networking with little to no down time. One major network facility would declare down time for server farm (access level) equipment upgrades. Me? At our facility, I pushed a cart up to a rack with a router and switch on it, with a few dozen pre-made cables. Since EIGRP converges near instantly, I broke and made one connection at a time, followed by clear ip route * and tested the connection. A small number of users on each path might have seen "destination not available", if they were initiating a connection, but on the second try they'd be fine. Then it was do the upgrade work and reverse the process, cutting back to the new equipment. Effectively speaking, there was no down time and no drama. Again, it's a matter of "thinking it through", prep and testing. Tech work is not political, emotional, etc. Really, it's just common sense.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
