Unable to restore from an ncp backup in docker

[Nitrousoxide]

Support intro

Sorry to hear you’re facing problems

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can

Nextcloud version: 20.0.4.0
Operating system and version (eg, Ubuntu 20.04): Docker running on Debien
Apache or nginx version (eg, Apache 2.4.25): nginx
PHP version (eg, 7.4): unknown

The issue you are facing:

Unable to restore from a ncp backup. When I attempt to use the gui in the 4443 instance of ncp of even a backup I just created for a freshly made container of NCP it will see the path but fail.

Here it sees the path to create a backup:

For some reason it says “invalid origin” but is nevertheless successfully creates the backup.

Which you can see here (Imgur album since i’m limited in the number of links)

[Album] imgur.com

When I go to restore this it sees the path as before, but will fail to perform the restore. It will create the directory to complete the restore but won’t put anything into it and does nothing further.

Any help would be greatly appreciated. I have an actual 32 gig backup I’m trying to restore right now, but am trying to understand the procedure because I’ve had no luck with that one ,and even a fresh install backup and restore is not working for me.

[OliverV]

From my (little docker) experience and memory, I have restored a docker instance by first removing the the old instance, then creating a new one using the -v (volume) option to mount the original volume with data and database in the volume.

What run command did you use to start and create your container?
Btw NCP uses Apache2 not Nginx, are you using nginx as a proxy maybe?
Log output can useful to troubleshoot…

[Nitrousoxide]

I have tried this, but then I get a bunch of permissions errors when it tries to start up. Keep in mind I’m not just trying to nuke the docker image and start a new container. I want to be able to take a backup of the appdata folder I have mounted to the container as the data directory from say a week ago and restore from that. I’m guessing NCP doesn’t use the same UID and GID as the regular container which is creating conflicting permissions problems? When I run ls -asl on the appdata directory created by the docker image I see several directories are owned by /www rather than root? Maybe it’s that’s the problem?

Do I have to manually tweak a bunch of directories to make their owners the original ones after copying them over? Or can I just pass a flag in docker to have it use a UID and GID that won’t create these weird permissions issues?

[Nitrousoxide]

I tried copying the nextcloud directory over and manually changing the directory and file owners to match the origional one’s That still had permission errors so I then just slapped sudo chmod -R 777 on the whole damn directory to see if giving EVERYONE permissions to do ANYTHING would work and that got me to this point with the docker logs.

Starting PHP-fpm

Starting Apache

AH00534: apache2: Configuration error: No MPM loaded.

Action ‘start’ failed.

The Apache error log may have more information.

Starting Redis

Starting Cron

Starting Postfix

ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)

Gotta say, I’m not overly impressed with the ability to restore from a backup here so far.

[eyduh]

How do you run up the docker instance?

Permission errors on docker are usually due to not setting uid/gid when running up the instance. If not set docker runs the application as root which is a security concern when dealing with web-applications specifically.

You can set the user id and group id of the docker processes using the environment flags PUID / GUID. If you simply want to set it to your user run id $user and set it accordingly.

example docker-compose and long explanation

In a docker-compose.yml file it would look something like:

---
version: "2.1"
services:
  nextcloud:
    image: theimage/youwant
    container_name: somethingcatchy
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
    volumes:
      - /path/to/appdata:/config
      - /path/to/data:/data
      - /path/to/backup:/Nextcloudbackup
    ports:
      - 443:443
    restart: unless-stopped

PID/GID 1000 is usually the id number of your main user.
You can also make a dedicated user for nextcloud(pi) and set that gid/pid with sudo userad -u 1337 -g 1337

( It could also be useful to set

    stdin_open: true # docker run -i
    tty: true        # docker run -t

to allow you to docker attach to the image in whichever way you prefer)

If you plan on opening up ssh from the ncp panel you should also map the port 25.

I never really use docker run as I like the layout of yml files and being able to save all my configs that way, but if you do like it then use -e PUID= and -e PGID= so set the IDs.

There’s some useful info on user/group IDs here:
linuxserver.io’s “Understanding PUID & GUID”
Their docker wiki is heaps useful, highly recommended.

---

Tl:dr;
Set pid/gid to any other user than root because running a web application as root is a security concern

sudo useradd -g -G www-data -u 1337 -p 1337 leet-ncp-user

then add PUID & GUID environment variables to the docker stack to match leet-ncp-user

Or if you are fine running it as your standard user, say Pi or Yourname, you can set them to 1000 in the docker-compose file. These users usually are in the sudo group which is only a security concern should you use the standard password.

Have a look at this thread regarding back/restores, might find somehting useful in there:
https://help.nextcloud.com/t/howto-change-move-data-directory-after-installation/17170

Another issue I’ve encountered not with nextcloud but with other containers using mysql/mariadb is that the database user gets mismatched between old/new containers. I’ve solved this by attaching to the image, then to the database and resetting the passwords.

[Nitrousoxide]

Thanks, this was very helpful. I did add those PUID and GUID env variables to my container. I was looking to see if they existed but didn’t find any documentation in the NCP docker instructions about what variables were allowed so… But after redeploying the container it says those flags are active and nothing seems to have broken so far.

I was able to import my data from my previous instance of NCP by flipping the permissions on the Nextcloud/nextcloud/data/ directory (a good ol’ sudo chmod -R 777 on it) so I can plop in my user’s directory from my backup, after I had first created a user with the same name in this new instance of NCP. After jumping into the NCP admin panel and having it scan for file changes and then having it reset file permissions it seemed to catch all that data just fine, though previous shares I’d provided to people were broken. I looked at your link there and I see that I would probably have to go and edit the sql database to fix those, for now I’ll just reshare them instead of trying to fix the previous shares.

Not the easiest restore I’ve done with a docker container, but it did mostly work (aside from restoring shares) so I’m comfortable enough starting up and using NCP again since I now have a tested backup and restore solution that actually worked.

[eyduh]

I’m glad it works now c:

NCP is mainly developed for on the metal installs, with some community members having made it available as a docker install - thus it is not optimized for that yet. That’s partly what this forum is for though ^^)

p.s.
I had a look at my Odroid HC4 on the metal install and the document root is chmod 751 which would be a bit more secure than 777 in case you want to do that.

[Nitrousoxide]

Yeah, I ran the “restore permissions” in the NCP admin panel and it popped the document root back to 771, which is probably fine since there’s only one user on this usergroup anyway.