The issue is caused by uploading bigger file (600MB) through WebUI. On WebDAV it silently fails. On WebUI, it break Nextcloud and haven't found a way to recover yet. This worked fine before the app overhaul.
Why is this persistent after restart of the app is beyond me.
Thanks for reporting it, please file a bug report with out developers on github for issues like these as this indeed looks to be, most likely, code related. We've seen 1 or 2 minor remarks about that before, but no one filed a report for it, so it hasn't been fixed yet.
For small bugs like these the response time when filing a bugreport is usually under 24 hours and the fix time most often under 48 hours.
I don't think containerization is the issue. I don't mean to offend anybody, but this just seems to be a badly written app which introduced breaking change and was not tested? Because I had basically no custom configuration, and it crashed on upgrade and my clean installation crashes while uploading large files. I used Nextcloud directly for years and I stitched my config together years ago, and it reliably performed ever since with minimum maintenance.
We agree that the previous App was badly writhen and borderline unmaintainable or, at the very least, very hard to improve on.
One of those issues was the bad structure of storage which had to be redone as well.
That's why we went ahead last month and have
completely remade it from scratch, which (sadly enough) requires users to (atleast) manually migrate their data.
If there is more assistance needed or more issues arise, we're opened our support tickets for this specific major change, due to community request and after having a few support staff members go over migration themselves.
We don't expect many breaking changes and always clearly tag them as semvar major (aka: potentially breaking) and try hard to send out announcents any time we can. We're very sorry people don't get the memo and have staff available to help everybody out, as we understand how inconvenient it might be.
To be 100% clear:
From, a technical perspective Nextcloud 15.x.x is a completely new app, compared to 14.x.x
Moving files were not all that was needed for me (forgot to mention). You also have to run some maintenance commands. I did this through the "OCC Web" app in Nextcloud once I got it to boot. But, if you mean just a blank, clean install, that does sound odd. Haven't seen that...
Care to relate?
Technically there isn't any change of actuall Nextcloud versioning or content on update from 14.x.x to 15.x.x, so nextcloud should (if the files are in their respective places) not "see" any relevant changes when updating from 14.x.x and 15.x.x
For new installs placing back the old files, it might be needed to scan all files using OCC.
OCC-Web is a good call by the way, we'll look into if we can add that by default to prevent users running into "how to occ" issues repeatedly, considering how getting into the shell is slight convoluted on Nextcloud.
It did have a string of issues, even before the .15 update. True. But, I think that still highlights the issue with containerization. You're basically outsourcing a part of your app maintenance. So, you really need to know who you are working with on a critical app, what testing is like and how much consideration is made for users in the wild. Without the containerization, you have better options to fix things.
We agree that there whas a string of issues in 14.x.x. Mostly due to how 14.x.x forced every single change into the main container, which caused an accident where a change wasn't completely pushed to the right container.
With 15.x.x all our code is mostly cut into more bite-sized smaller pieces, so we expect less of these issues.
In terms of testing:
Our CI tests, by the nature of major version changes, exclude upgrade testing between major releases. We will look into if we can improve or modify that behavior in the future.
I suspect the issue for you is that you were supposed to have read the manual migration "instructions" before updating. But, those instructions aren't the most robust, even if you did see them before updating:
View attachment 56709
We agree that this announcement wasn't the most thorough.
We are working on completely reworking our documentation backend and will take to heart to put more effort into putting migration guidelines directly in the manual in the future.
This sounds like simply moving the entire data path to html. But, that didn't work for me either. I had to set up the same path for both data and html to get it to boot, which doesn't seem like the right solution long term, either. It's just not clear enough for something that is likely to break things for a lot of users if done wrong.
We do not advice that, instead we advice TrueTool PVC mounting to manually move the data between the PVC's and ensure that data is left in the data PVC (or moved to a hostPath mountpoint) while the rest is moved to the html PVC.
For more detail be sure to ask our staff!
One just responded with a full-go-ver on one of the recent support tickets :)
It can be worse. In my case, they've acknowledged that the "support" I got led to a broken install. But, still leave me banned and with a hostile impression.
We do acknowledge that we're sorry you
misunderstood our support staff their assistance.
Imagine if I had relied on this for a business on a mission critical project?! It's just not viable to risk being put in that position over petty behavior.
With any form of community and opensource support, you might get banned when you do not follow their rules. Whatever those rules might be. This, for example, includes the iX-Forums or OpenZFS Github, to name a few often mission-critical pieces of software with community support.
If you need business-level support for mission critical processes, it's always adviseable to see if you can get commercial support with a contract.
We've even discussed this among our staff and there definately are options to get something like this set-up, in case people are interested. Anyone is free to throw us an email or DM somewhere to see what we make happen! :)
It's like being forced to hire an employee that is pre-emptively disgruntled because they aren't getting paid.
It's fair to assume most slaves would be pre-emptively disgruntled because they aren't getting paid.
