Something is broken in Nextcloud after moving to sub domain (and back)

Discuss Advanced use case
1

I have a broken Nextcloud installation, it seems. I moved the installation around a bit, and now I can’t get it running and I am not sure where to start troubleshooting.

This is the order of changes:

  1. Nextcloud is running ok at home via sanyi.nl/nextcloud
  2. Moved on that server at home to cloud.sanyi.nl/
    2a *
  3. Backed up (core-only)
  4. Restored at VPS
  5. It does not work now, on the VPS and reachable via cloud.sanyi.nl/
  6. Moved on the VPS back to sanyi.nl/nextcloud

2a: my ISP took the IP away, the server was not reachable without an entry in /etc/hosts ; I am quite sure it worked back then.

Symptoms at the moment:

  • Log in to Yunohost SSO and then Nexctloud: internal server error at sanyi.nl/nextcloud/apps/dashboard/ , with a message to have a look in the log, my IPv6 and a request ID. Nginx access log only gives a couple of lines, "GET /apps/files?sso_login=8029225...189F7894C603 HTTP/2.0" 302 154 "https://sanyi.nl/yunohost/sso/?r=9jbG91ZC5z...S5ubC" "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0"
  • Log in to Nextcloud directly hangs eternally; /var/log/nginx/sanyi.nl-access.log keeps redirecting:

2001:985:b79a::2000 - - [30/Oct/2021:19:31:01 +0100] "POST /nextcloud/sanyi.nl HTTP/2.0" 302 0 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0"
2001:985:b79a::2000 - - [30/Oct/2021:19:31:01 +0100] "GET /nextcloud/login HTTP/2.0" 200 3743 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0"
2001:985:b79a::2000 - - [30/Oct/2021:19:31:01 +0100] "POST /nextcloud/sanyi.nl HTTP/2.0" 302 0 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0"
2001:985:b79a::2000 - - [30/Oct/2021:19:31:01 +0100] "GET /nextcloud/login HTTP/2.0" 200 3741 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0"
2001:985:b79a::2000 - - [30/Oct/2021:19:31:01 +0100] "POST /nextcloud/sanyi.nl HTTP/2.0" 302 0 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0"
2001:985:b79a::2000 - - [30/Oct/2021:19:31:01 +0100] "GET /nextcloud/login HTTP/2.0" 200 3743 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0"

(quite fast, 10+ lines per second)

Where should I look for more useful logging?

Could the cause be that I didn’t backup (nor restore) the data?

Edit: Nextcloud is at version 20 at the moment. With the backup at hand, I’ll try running the upgrade to version 22, and see where that leads.

2

Try entering the ip address instead of the domain name as dns propagation takes some time.
See what the diagnosis says.
Try installing a fresh nextcloud and replace the config.php with the old one and see if it works

3

Thanks, I didn’t think of the diagnosis. It has helped me out quite often, but this time it does not give helpful hints. There are two warnings (about using buster backports, and about DNS IPv6 wildcard @ for vpn.sanyi.nl), no errors. Should sharing from diagnosis work? It gives me:

**Error**: `"400" Bad Request`

**Action**: `"GET" /yunohost/api/diagnosis/show?share&locale=en`

**Error message:**

The following categories are unknown: show

The change of IP for the domains was a while (days? weeks?) ago, it resolves correctly.

Would that be var/www/nextcloud/config/config.php? I’ll give it a try. At the moment the bits that seem domain-related are:

  'trusted_domains' => 
  array (
    0 => 'localhost',
    1 => 'sanyi.nl',
  ),
  'datadirectory' => '/home/yunohost.app/nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '22.2.0.2',
  'overwrite.cli.url' => 'https://sanyi.nl',

There is no reference to the nextcloud subdirectory, but that might be in Nginx-config.

Would you have an idea where to look for logging, apart from nginx access/error?

By the way, upgrading from version 20 to 22 did not make a change (as expected, but you never know!)

4

Try

/var/www/nextcloud/data/nextcloud.log

5

Ah thanks! not there, but the nextcloud/data bit triggered me to have a look and yes, it is in /home/yunohost.app/nextcloud/data/nextcloud.log

It is not the most readable of logs, but it seems rights related:

"message":"Could not create path","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0","version":"22.2.0.2","exception":{"Exception":"OCP\\Files\\NotPermittedException","Message":"Could not create path","Code":0,"Trace":[{"file":"/var/www/nextcloud/lib/private/Files/SimpleFS/NewSimpleFile.php"

That is strange, the whole path does not exist. I can make the path, but I can’t set user rights for Nextcloud:

# mkdir -p /var/www/nextcloud/lib/
# chown -R nextcloud:nextcloud /var/www/nextcloud
chown: invalid user: ‘nextcloud:nextcloud’

Something must be off with the installation / restore. Removing Nextcloud and installing it from scratch will/should give a working installation, but it will probably be quite a hassle to import user data and settings.

Any suggestions?

6

If it’s only about copying data from a nextcloud server to another, you can try make sure the first one is running correctly, install a clean one in the destination server, add your users, for every user make an external storage (nextcloud with corresponding username and password), you can authorise your users to add their own external storage in settings. The data will be available in the directory defined in settings. The user can copy the hole thing to the new nextcloud installation.
How many users have you? Are they confortable with tech?

7

It is only a handful of users, but not too interested in tech (family and friends of my children, mostly).

The data is the easiest part, and can I copy via the filesystem, followed by an oc_filescan (something like that). It is mostly reinstalling the apps, configuring things. I guess that calendars/address books will be re-filled by the clients connecting, if not I can still copy them from the old database.

No data is lost and all can be retrieved, things just take more time than I anticipated (… which I could have expected :stuck_out_tongue: )

First I see if the current installation is still salvable.

The nextcloud user does not exist, but file permissions were retained during restore:

# ls -hals /home/yunohost.app/nextcloud/data
total 12M
8.5K drwxr-x--- 12  998  998   18 Apr 27  2021 .
 512 drwxr-xr-x  3 root root    3 Mar 28  2020 ..
8.5K drwxr-x--- 14  998  998   14 Jan 12  2021 appdata_oc0tp3srxddx
4.5K -rw-r-----  1  998  998  11K Oct 30 13:25 audit.log

After adding the nextcloud user with that ID I could chown the nextcloud directories,

# useradd -u 998 nextcloud
# chown -R nextcloud /var/www/nextcloud
# chown -R nextcloud:nextcloud /home/yunohost.app/nextcloud/data/

I was hoping to find an OCC command that repairs permissions, so I ran /var/www/nextcloud/occ:

# sudo -u nextcloud php /var/www/nextcloud/occ
An unhandled exception has been thrown:
OC\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)

After chowning to nextcloud:nextcloud the nextcloud dir in www and the nextcloud dir in yunohost.app, things got worse, so that might not have been the best idea. Now accessing Nextcloud via the web gives access denied, instead of eternal redirects :frowning:

When comparing the broken installation to another Nextcloud that is running fine, I don’t see obvious differences in file ownership,

# getfacl /var/www/nextcloud/index.php 
getfacl: Removing leading '/' from absolute path names
# file: var/www/nextcloud/index.php
# owner: nextcloud
# group: nextcloud
user::rw-
group::r--
other::r--

is identical while in the log of the broken installation

# tail /var/www/nginx/sanyi.nl-error.log
....
2021/10/31 08:21:16 [error] 16337#16337: *26476 "/var/www/nextcloud/index.php" is forbidden (13: Permission denied), client: 2001:985:b79a::2000, server: sanyi.nl, request: "GET /nextcloud/ HTTP/2.0", host: "sanyi.nl"
2021/10/31 08:34:12 [error] 1023#1023: *8 "/var/www/nextcloud/index.php" is forbidden (13: Permission denied), client: 2001:985:b79a::2000, server: sanyi.nl, request: "GET /nextcloud/ HTTP/2.0", host: "sanyi.nl", referrer: "https://sanyi.nl/yunohost/sso/"

The installation on the old server got broken, one way or another. I tried restoring from backups, but both the backups I have are broken/don’t work because of file permissions for a removed user. I think it is time to give up on this installation of Nextcloud :frowning:

Thank you for your trouble!

8

:-/

After removing the installation and reinstalling Nextcloud, I was quite surprised to see the server populated with files. It turns out that Nextcloud was actually running fine, but only the web frontend did not work.

I have no idea how to repair the web frontend, so I’ll stay with the new installation and reconfigure it to match the old installation. It is not the most satisfactory result, but I think for future use (and upgrades) it is better not to have a Frankencloud of various bits and pieces from different Nextcloud installations.

1 Like