So, I moved my nextcloud directory from a local SATA drive to a NFS mount from a nvme array on a 10G network
“I just need to change /docker/nextcloud to /mnt/nfs/nextcloud in the docker-compose.yml, what’s the issue, i do it live” - i tell myself
So i stop the container, copy /docker/nextcloud to /mnt/nfs/nextcloud, then edit the docker-compose.yml… and… because I’m doing it during a phone call without paying too much attention i change the main directory to /docker
I rebuild the container and I immediately hear a flood of telegram notifications from my uptime-kuma bot… oh oh…
Looks like the nextcloud docker image has an initialization script that if it doesn’t find the files in the directory, it will delete everything and install a fresh copy of nextcloud… so it deleted everything on my server
Luckily i had a very recent full borg backup and i’m restoring it (i kinda love-hate borg, i always forget the restore commands when in panic and the docs are a bit cryptic for me)
Lessons learned:
always double check everything
offsite backups are a must (if i accidentally wrote / as path, i would have lost also the borg backups!)
offsite backups should not be permanently mounted, otherwise they would have been wiped as well
learn how to use and schedule filesystem snapshots, so the recovery wouldn’t take ages like it’s taking right now (2+ hours and i’m not even half way…)
OP said he’s been using a Docker image that it’s “official by Docker”, and not the AIO image official by Nextcloud. The issue here is a random contributor on GitHub’s docker organization. Afaik those images are not carefully tested, docker, as many floss organizations rely primarily on contributors, and plenty of these are amateurs or students trying to build a profile…
I believe the --delete option is the problem here, it will delete all files in the target dir that aren’t in the source dir.
Ironically, the script even has a directory_empty function it could use to double-check the target dir, but it doesn’t use it for this particular dir. 😆
So, bottom line, a Nextcloud install will wipe out the target dir if you’re not careful and I stand by my decision to not touch it with a ten-foot pole.
On an unrelated note: yeah it’s confusing that the official Nextcloud AIO docker image is not on Docker Hub and what you get when you search for nextcloud is a “Docker official image” that’s actually community-maintained. But as I said in my other comment in this particular case the problem exists in both images.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
Welp that’s it, I’m never using Nextcloud.
yeah thats what im taking away from this too… you dont just rm -rf shit in any application without some good ass verification from the user
OP said he’s been using a Docker image that it’s “official by Docker”, and not the AIO image official by Nextcloud. The issue here is a random contributor on GitHub’s docker organization. Afaik those images are not carefully tested, docker, as many floss organizations rely primarily on contributors, and plenty of these are amateurs or students trying to build a profile…
The script that killed OP’s files (
entrypoint.sh) also exists in the official Nextcloud AIO image, and the offending line is there as well:I believe the
--deleteoption is the problem here, it will delete all files in the target dir that aren’t in the source dir.Ironically, the script even has a
directory_emptyfunction it could use to double-check the target dir, but it doesn’t use it for this particular dir. 😆So, bottom line, a Nextcloud install will wipe out the target dir if you’re not careful and I stand by my decision to not touch it with a ten-foot pole.
On an unrelated note: yeah it’s confusing that the official Nextcloud AIO docker image is not on Docker Hub and what you get when you search for nextcloud is a “Docker official image” that’s actually community-maintained. But as I said in my other comment in this particular case the problem exists in both images.