I have also found that if you stick to the core functionality it works fine.

As soon as I started to add apps from the store it starts to be a pain. An upgrade comes out and you’re stuck on that version until they all update, OR you update not realizing and lose the functionality for some time.

Since I self-host a bunch of apps, it made more sense to use different apps dedicated to those features, like Miniflux or Navidrome. Not for everybody though.

I ran NextCloud for some years, just for the file sharing. I was the only user. About every third upgrade cocked up in some critical way that required bespoke DB fixes. Twice I basically blew away all state and recreated my entire file store from scratch from a backup because it was easier than fixing the install. Worked for me but is infeasible for any larger install. I tried using the office functionality for one document and I lost the document entirely on an upgrade because apparently the mirroring as a file is an illusion and the real office data is stored buried in the database in a way I never did manage to recover; I ended up just recreating the document. Thank goodness it was just the one document.

It is constantly screaming for upgrades but I don't know what they are doing with those upgrades because it doesn't seem to make the core any more reliable. It's just an opportunity for the upgrade to fail and lose data, which it frequently took advantage of.

The key thing that really annoyed me is that I couldn't hardly have used it more lightly than I did, and it took about every other opportunity to fall over and lose data. I can't even imagine the plight of someone trying to run this in an office environment.

I gained working music and RSS that week.

If you use docker + watchtower all this is done automatically

I don’t use Watchtower, but a script that takes a btrfs snapshot before doing a docker compose pull, then docker compose up.

Same idea, just safer and fewer surprises.

That's nice and simple, do you have a shareable version of this script or some advice on btrfs pointers/pitfalls?

It's really just those three steps in a loop, nothing fancy

    SHOT_TIME="$(date +'%Y-%m-%d_%H-%M')"
          
    for dir in /docker/*
    do
        cd $dir;
        btrfs subvolume snapshot "${dir}" "/docker/.snapshots/$(basename $dir)-${SHOT_TIME}"
        docker compose pull --quiet
        docker compose up -d
    done

I mount a btrfs subvolume at /docker, and create a .snapshots subvolume inside.

Each subvolume is an app and its dependencies, you want everything snapshotted as one. This is probably the biggest pitfall, if you don't take that snapshot of all the pieces.

    /docker
    |--> .snapshots
         |--> app_one-2024-08-28_12-34
    |--> app_one
         |--> compose.yaml
         |--> volumes
              |--> app_one-config
              |--> app_one-db
    |--> app_two
         |--> compose.yaml
         |--> volumes
              |--> app_two-config
              |--> app_two-db

> Not once had I any serious issues updating when pulling new updated images

I've run it for about a year until the upgrade tipped me over. I am sure that correct upgrades (n to n+1) are fine - I tried n to n+2 and instead of explaining to me that this is not possible, Nextcloud explained to me that this is not possible and fucked up big my install. I had to recover from a backup.

Strange, my experience is that, if I don't upgrade in a while, the automatic updater goes to the next version, and after installing it it tells me there's another update and so on. Or maybe you didn't use the built-in updater?

I did use the built in updater. It was 3 or 4 years ago so things may have changed

Why did you do that when the instructions say not to?

I don't understand why this attitude is so prevalent in the tech industry. The person writing the upgrade script knows if upgrades can't support n+2 jumps and it takes about 30s to build in a check:

    if(target_version > current_version + 1) // not allowed

It's more work to add it to the docs than it is to put a fail-fast check in the upgrade script, so why put it in the docs where 250k+ admins need to be aware of the limitation and avoid it?

It might be creating 100k hours of waste on the sysadmin side to save 30m of work on the dev side. I just don't get it.

This is, of course, exactly what Nextcloud does. It will most certainly refuse to run and break your system. And yes, it also refused that 3-4 years ago.

Not saying it never breaks anything, but since 2016 we for example check PHP versions and other infra to not update to a broken system. We rewrote the updater in 2016 for this purpose. It's possible this has had a bug at some point of course - but it is more likely that the original poster who had this issue had this in the ownCloud times before 2016.

It's to sit at the top of the tower smugly. I know because truthfully I enjoy it myself from time to time, we all do in our own little ways. :^)

Seriously do you think that for software that manages data the proper way is for someone who starts the upgrade process to say "this is not supported, and now we fucked up your database and you cannot recover from that"? They knew that I was upgrading N+2, this is not a surprise - and I did not realize that upgrading N+2 is not supported.

The proper way would be to abort the upgrade upon discovering that I am going for an unsupported way.

This is not serious software.

I don't understand how commenters here can seriously argue this. There should be no UX for "oh this is not supported? Eh give it a shot anyway, I don't care about literally all my files".

If you don't support upgrading, don't expose that in the UI. There's no excuse for having UI that will let the user do something unsupported and then screw up their data.

Not saying it's the case here, but I wonder how much deniably malicious incompetence out there gets covertly injected into projects by competitors.

That's a very interesting conspiracy theory, I assume the amount is nonzero.

It's risky business, though, as code of course gets reviewed a few times (at least at Nextcloud). If it gets detected once ppl are put on notice. If somebody can squirrel out that the code came from a competitor, a lawsuit is waiting... And just imagine the bad publicity it causes.

Besides that, it is unethical and I wouldn't want to work at a company that pulls such stunts. I think a lot of people wouldn't. It'd be hard to keep secret, too, I mean, 5 years later the employee that was asked to do it works somewhere else and BOOM.

So all together, I think it's extremely unlikely to happen.

I CAN imagine a disgruntled ex employee or angry employee at a competitor would pull something like this. We have seen employees at a competitor create social media sock puppet accounts to spread FUD about us - but management at the competitor put a stop to that once we notified them.

What do you do to make performance not suck? Have been using it for years, but it just sucks in terms of showing me my pictures.

Also, what do iOS people do to make their auto upload folders upload automatically without having to open the app?

After using Nextcloud for a while i stopped, since it was to buggy, and always took an eternity to load simple pages like the dashboard.

So i decided to switch to dedicated services, instead of using nextcloud to handle everything.

For images i can recommend Immich which is a new open source project specializing in storing your images with local AI support. I can highly recommend it.

beware of leaving an open upload on Photoprism for example -- close your uploads to $public on any photo host IMHO

The Memories app is a LOT faster than the built in Photos app. I use it myself and it's quite nice, very doable on my down clocked old Intel CPU.

I had version 17 installed, I wanted to upgrade to version 20.

I launched the container for the new version, but got an error: "Exception: Updates between multiple major versions and downgrades are unsupported."

I then tried launching the container for version 18, which should be supported, which initially seemed to succeed! However, I was greeted by "Internal Server Error" in the web UI, since apparently instead of just quitting, the initial upgrade had ruined the DB schema.

After restoring version 17 from backup, migrating to 18 and onwards, then trying to register my local apps with it, I then got CSP errors in the console when signing in. After manually editing the configuration file (which you seemingly can't do through environment variables) that seemed to be resolved.

Then, I tried syncing my local files but realized that the size of all of them is suddenly 0 KB. The files would show up in the web UI, but the size would be 0 KB. I had to rename the files a few times, which eventually fixed that, no matter how odd.

Finally, I realized that trying to open any of the pages in the web UI would take around 3-10 seconds. It seemed that there was a bug in the Talk application, disabling which then gave me the expected performance, even if it affecting how the Files application works also seems odd.

I like the utility Nextcloud provides me, but despise updating it. At this point I just stick to the core apps and wipe the whole thing when I need to update to something newer, manually carrying over the files I want to sync in the new instance.

Oh, also, out of the box the DB file locking configuration causes large file uploads (a few GB) to just hang, in a way where I cannot delete them. I had to disable locking altogether.

Honestly, it's just weird. If you need 1000 SQL migrations to go from version 1 of your software to version 20, just include all of them and don't mess around with disallowing migrating across multiple major versions. Same for any changes that might impact the persisted files on the FS. Just have updates be one continuous, long stream of patches, applied sequentially. If you do that and have sane defaults, you're good.

To not be overly negative: it's good that Nextcloud exists, is free, has a somewhat nice ecosystem around it and both the desktop apps and the phone apps for iOS/Android are okay.

I remeber having some issues when I first attemped running a Nextcloud Docker container years ago. I don't know it it was because it was one of my first times with Docker or if it was Nextcloud that was screwing-up, but a native (non Docker) install solved all my problems. Was rock-solid ever since, up when I retired it recently due to unrelated reasons.

Maintaining a server can be a pita, and not upgrading frequently is both a security risk as well as problematic from a stability pov.

My recommendation would be to use our All-in-One docker image. It takes care of updates and is supremely easy to use, plus likely to bring nice performance benefits as it has all this stuff that makes it fast like the HPB for Files.

This has been my experience as well. The only major instability was due to the Ubuntu snap based runtime, which I migrated away from a few years ago.