[Support] Linuxserver.io - Nextcloud

[iXNyNe]

docker exec -it nextcloud touch /config/www/nextcloud/config/needs_migration
docker restart nextcloud

Then rescan using the link in the Nextcloud admin status page.

 

That should fix the integrity check. Running the occ command should not be needed, and without the steps above it won't fully fix the issue.

[TwistedCarnivore]

12 minutes ago, iXNyNe said:

docker exec -it nextcloud touch /config/www/nextcloud/config/needs_migration
docker restart nextcloud

Then rescan using the link in the Nextcloud admin status page.

 

That should fix the integrity check. Running the occ command should not be needed, and without the steps above it won't fully fix the issue.

 

Did that again. It shows upgrading in the log when the container starts, but still showing same 10 extra files in integrity check. I did run all the occ commands that he showed in the discord post, and that didn't help either. 

 

Guess I just have a persistent poltergeist. Probably just wait for the next version to roll out and see what happens then . 

using keys found in /config/keys
Initializing nextcloud 27.0.0.8 (this can take a while) ...
Upgrading nextcloud from 27.0.0.8 ...
Setting permissions
Nextcloud is already latest version
Initializing finished

 

 

[iXNyNe]

19 minutes ago, TwistedCarnivore said:

 

Did that again. It shows upgrading in the log when the container starts, but still showing same 10 extra files in integrity check. I did run all the occ commands that he showed in the discord post, and that didn't help either. 

 

Guess I just have a persistent poltergeist. Probably just wait for the next version to roll out and see what happens then . 

using keys found in /config/keys
Initializing nextcloud 27.0.0.8 (this can take a while) ...
Upgrading nextcloud from 27.0.0.8 ...
Setting permissions
Nextcloud is already latest version
Initializing finished

 

 

you can delete the listed files manually to make it go away.

[levster]

On 7/3/2023 at 9:00 AM, iXNyNe said:

Deleting the apps folder shouldn't cause this.

Crashing is usually preceded by errors in the container log or application log files. In the case of nextcloud this could be the nginx log in /config/logs or more likely in the nextcloud log in /data

 

You had previously posted what looked like the nextcloud log with the php errors, which is what made me think it was a problem with the apps.

 

At this point, since you have backups I would recommend setting one of the last known good backups aside somewhere so it doesn't rotate out when new backups are made, and then try completely deleting your nextcloud appdata and try doing a fresh install (may also need to make a new database, and possibly rename your nextcloud data folder to be sure there's no conflicts). If a fresh install of nextcloud has the same issues I'll be pretty stumped. If it works, then we just need to figure out what's going wrong with your current install. 

 

So, I finally decided and pulled the trigger. Wiped all of the dockers relating to Nextcloud - MariaDB, Swag and Nextcloud and followed Spaceinvader One video to a t. When trying to launch the WebUI I get This site can’t be reached, and in the Nextcloud log the following line:

 

Can't start Nextcloud because the version of the data ('27.0.0.8) is higher than the docker image version (27.0.0.8) and downgrading is not supported. Are you sure you have pulled the newest image version?

 

How do I proceed?

 

 

[iXNyNe]

16 minutes ago, levster said:

 

So, I finally decided and pulled the trigger. Wiped all of the dockers relating to Nextcloud - MariaDB, Swag and Nextcloud and followed Spaceinvader One video to a t. When trying to launch the WebUI I get This site can’t be reached, and in the Nextcloud log the following line:

 

Can't start Nextcloud because the version of the data ('27.0.0.8) is higher than the docker image version (27.0.0.8) and downgrading is not supported. Are you sure you have pulled the newest image version?

 

How do I proceed?

 

 

There looks to be an extra single quote in there. Check your config.php

[levster]

12 minutes ago, iXNyNe said:

There looks to be an extra single quote in there. Check your config.php

Here is the config.php (\\TOWER\cache\appdata\nextcloud\www\nextcloud\config)

 

'<?php
$CONFIG = array (
  'datadirectory' => '/data',
  'instanceid' => '***************',
  'passwordsalt' => '******************',
  'secret' => '**********************',
  'trusted_domains' => 
  array (
    0 => '192.168.1.130:444',
    1 => 'nextcloud.mysite.com',

  ),
  'trusted_proxies' => ['swag'],

  'dbtype' => 'mysql',
  'version' => '27.0.0.8',
  'overwrite.cli.url' => 'https://nextcloud.mysite.com/',
  'overwritehost' => 'nextcloud.mysite.com',
  'overwriteprotocol' => 'https',
  'dbname' => 'nextcloud',
  'dbhost' => '192.168.1.130:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'user',
  'dbpassword' => 'password',
  'installed' => true,
);
 

[levster]

1 hour ago, levster said:

Here is the config.php (\\TOWER\cache\appdata\nextcloud\www\nextcloud\config)

 

'<?php
$CONFIG = array (
  'datadirectory' => '/data',
  'instanceid' => '***************',
  'passwordsalt' => '******************',
  'secret' => '**********************',
  'trusted_domains' => 
  array (
    0 => '192.168.1.130:444',
    1 => 'nextcloud.mysite.com',

  ),
  'trusted_proxies' => ['swag'],

  'dbtype' => 'mysql',
  'version' => '27.0.0.8',
  'overwrite.cli.url' => 'https://nextcloud.mysite.com/',
  'overwritehost' => 'nextcloud.mysite.com',
  'overwriteprotocol' => 'https',
  'dbname' => 'nextcloud',
  'dbhost' => '192.168.1.130:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'user',
  'dbpassword' => 'password',
  'installed' => true,
);
 

I think that I managed to "fix" this issue. I reinstalled the entire trio one more time, paying close attention to the logs, and in the initial Nextcloud log, right after the first launch, here is what is in the log:

 

Setting resolver to  192.168.1.1
Setting worker_processes to 32
generating self-signed keys in /config/keys, you can replace these with your own keys if required
Initializing nextcloud 27.0.0.8 (this can take a while) ...
Setting permissions
New nextcloud instance
Please run the web-based installer on first connect!
Initializing finished
After completing the web-based installer, restart the Nextcloud container to apply default memory caching and transactional file locking configurations.
Alternatively, you can apply your own configurations by editing /config/www/nextcloud/config/config.php following the documentation:
https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html
https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/files_locking_transactional.html
# do daily/weekly/monthly maintenance
# min   hour    day     month   weekday command
*/15    *       *       *       *       run-parts /etc/periodic/15min
0       *       *       *       *       run-parts /etc/periodic/hourly
0       2       *       *       *       run-parts /etc/periodic/daily
0       3       *       *       6       run-parts /etc/periodic/weekly
0       5       1       *       *       run-parts /etc/periodic/monthly
# nextcloud cron
*/5     *       *       *       *       s6-setuidgid abc php -f /app/www/public/cron.php
[custom-init] No custom files found, skipping...
[ls.io-init] done.
Exception: Not installed in /app/www/public/lib/base.php:285
Stack trace:
#0 /app/www/public/lib/base.php(705): OC::checkInstalled()
#1 /app/www/public/lib/base.php(1173): OC::init()
#2 /app/www/public/cron.php(43): require_once('...')
#3 {main}

 

I am not sure if following this did the trick, or it was something else, but, for the time being I am in Nextcloud WebUI.

 

 

[iXNyNe]

7 hours ago, levster said:

I think that I managed to "fix" this issue. I reinstalled the entire trio one more time, paying close attention to the logs, and in the initial Nextcloud log, right after the first launch, here is what is in the log:

 

Setting resolver to  192.168.1.1
Setting worker_processes to 32
generating self-signed keys in /config/keys, you can replace these with your own keys if required
Initializing nextcloud 27.0.0.8 (this can take a while) ...
Setting permissions
New nextcloud instance
Please run the web-based installer on first connect!
Initializing finished
After completing the web-based installer, restart the Nextcloud container to apply default memory caching and transactional file locking configurations.
Alternatively, you can apply your own configurations by editing /config/www/nextcloud/config/config.php following the documentation:
https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html
https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/files_locking_transactional.html
# do daily/weekly/monthly maintenance
# min   hour    day     month   weekday command
*/15    *       *       *       *       run-parts /etc/periodic/15min
0       *       *       *       *       run-parts /etc/periodic/hourly
0       2       *       *       *       run-parts /etc/periodic/daily
0       3       *       *       6       run-parts /etc/periodic/weekly
0       5       1       *       *       run-parts /etc/periodic/monthly
# nextcloud cron
*/5     *       *       *       *       s6-setuidgid abc php -f /app/www/public/cron.php
[custom-init] No custom files found, skipping...
[ls.io-init] done.
Exception: Not installed in /app/www/public/lib/base.php:285
Stack trace:
#0 /app/www/public/lib/base.php(705): OC::checkInstalled()
#1 /app/www/public/lib/base.php(1173): OC::init()
#2 /app/www/public/cron.php(43): require_once('...')
#3 {main}

 

I am not sure if following this did the trick, or it was something else, but, for the time being I am in Nextcloud WebUI.

 

 

That's normal. The scheduled task runner triggers before you've completed the web UI first time setup, and it depends on the setup being complete. Nothing to worry about.

[jj_uk]

Hi- I'm trying to fix nextcloud following the instructions here: https://info.linuxserver.io/issues/2023-06-25-nextcloud/ but i'm stuck.

 

I changed the repository back to lscr.io/linuxserver/nextcloud:version-24.0.12 and restarted.

 

I had some warnings about /nextcloud/nginx/nginx.conf and /nextcloud/nginx/site-confs/default.conf being out of date, so i deleted them and restarted the container. They were recreated.

 

The log file now shows only this:

Quote

 

Could not open input file: /app/www/public/cron.php

 

 

 

 

When accessing the nextcloud webgui ip address, I get this:

 

Quote

Internal Server Error The server encountered an internal error and was unable to complete your request. Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report. More details can be found in the webserver log.

 

When trying to update, I get this:

 

 

I read my notes from past updates and run the command that I always use:

 

sudo -u abc php /config/www/nextcloud/updater/updater.phar

 

but get the same write permission error as above.

 

Here's my nextcloud appdata, the user/group seems to be nobody/nogroup. I can't remember if this was user/group abc/abc previously?

 

 

I'm now stuck and don't know what to do to get nextcloud working again?  I've tried as much as I can, but this is beyond me.

 

EDIT:

 

I ran 

chown -R abc:abc /config/www

sudo -u abc php /config/www/nextcloud/updater/updater.phar

The updater is now running. We'll see what happens.

 

EDIT 2: 

 

This is working for me. Nextcloud updated once and I was able to access the GUI.

 

 

Edited July 9, 2023 by jj_uk

[levster]

After setting a new instance of Nextcloud I have the following warnings:

 

The "X-Content-Type-Options" HTTP header is not set to "nosniff". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

The "X-Frame-Options" HTTP header is not set to "SAMEORIGIN". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

The "X-XSS-Protection" HTTP header does not contain "1; mode=block". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

 

I checked and in the nginx/site-confs/default.conf these are all listed. Should they be elsewhere? 

 

[iXNyNe]

50 minutes ago, levster said:

After setting a new instance of Nextcloud I have the following warnings:

 

The "X-Content-Type-Options" HTTP header is not set to "nosniff". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

The "X-Frame-Options" HTTP header is not set to "SAMEORIGIN". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

The "X-XSS-Protection" HTTP header does not contain "1; mode=block". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

 

I checked and in the nginx/site-confs/default.conf these are all listed. Should they be elsewhere? 

 

If you're using swag as a reverse proxy make sure your configs for swag are up to date (check the container log). If you're using something else, there may be a conflict in the configurations between the proxy and nextcloud. If you're accessing directly without a proxy then we've got something wrong in the nginx confs and will have to investigate a fix.

[nraygun]

I see this in the Background jobs page: Last job execution ran 8 days ago. Something seems wrong.

 

Is this also something that will get addressed when they issue the next update? I'm on 27.0.0-ls252 at the moment.

[stiernacken]

On 7/6/2023 at 3:53 AM, iXNyNe said:

The pdlib extension for php 8.2 does not seem to be available in the alpine package repository. There is a pdlib extension for php 8.0 in edge/testing, but we need 8.2.

 

This is the search for the package:

https://pkgs.alpinelinux.org/packages?name=php*pdlib*&branch=edge&repo=&arch=x86_64&maintainer=

We need one specifically named php82-pdlib

 

The file you named is there sind 08.07.23 what to do with that file?

[iXNyNe]

9 hours ago, nraygun said:

I see this in the Background jobs page: Last job execution ran 8 days ago. Something seems wrong.

 

Is this also something that will get addressed when they issue the next update? I'm on 27.0.0-ls252 at the moment.

rename /config/crontabs to something else like /config/crontabs.bak and then restart the container. it will recreate the folder. compare the files in your renamed backup folder to the files in the newly created folder. if you intentionally customized anything, you can reapply your customizations. the line it comes with should not be modified though, it would just be if you needed to add extra lines. you can delete the renamed backup folder once you've confirmed you have any customizations reapplied (or didn't have any to apply).

[iXNyNe]

4 hours ago, stiernacken said:

 

The file you named is there sind 08.07.23 what to do with that file?

You can read https://www.linuxserver.io/blog/2019-09-14-customizing-our-containers and use a custom-cont-init.d script. I'm not going to go into a lot of detail on this because it's kind of advanced, and we document the general concepts, but not the specifics because we can't support every customization everyone wants to do (thus the DIY approach documented in the blog post). If you can figure out how to install the extension via the custom init script you'll be all set. If not I would advise you wait until a stable release of the extension is available. It would have to show up in a branch that isn't testing and has an actual release version number like 3.19 (if it gets included there in the future). alpine very rarely adds new packages to existing releases, so it's unlikely we would see it in 3.18 or below.

[levster]

22 hours ago, iXNyNe said:

If you're using swag as a reverse proxy make sure your configs for swag are up to date (check the container log). If you're using something else, there may be a conflict in the configurations between the proxy and nextcloud. If you're accessing directly without a proxy then we've got something wrong in the nginx confs and will have to investigate a fix.

I am using Swag and do not see anything odd in the log. 

 

Also, I am seeing a lot of these:

Errorno app in contextOCP\Security\Bruteforce\MaxDelayReached: Reached maximum delay2023-07-10T08:27:41-0400

 

ntextOCP\Security\Bruteforce\MaxDelayReached: Reached maximum delay

/app/www/public/lib/private/User/Session.php - line 431:

OC\Security\Bruteforce\Throttler->sleepDelayOrThrowOnMax()

/app/www/public/lib/private/User/Session.php - line 580:

OC\User\Session->logClientIn("*** sensiti ... *")

/app/www/public/lib/base.php - line 1143:

OC\User\Session->tryBasicAuthLogin()

/app/www/public/ocs/v1.php - line 61:

OC::handleLogin()

/app/www/public/ocs/v2.php - line 23:

require_once("/app/www/public/ocs/v1.php")

Errorno app in contextOCP\Security\Bruteforce\MaxDelayReached: Reached maximum delay2023-07-10T08:27:41-0400

Errorno app in contextOCP\Security\Bruteforce\MaxDelayReached: Reached maximum delay2023-07-10T08:27:37-0400

Errorno app in contextOCP\Security\Bruteforce\MaxDelayReached: Reached maximum delay2023-07-10T08:22:31-0400

 

On a side note, when I go to update my personal info, the email address cannot be changed from something that I used a long time ago. As soon as I change it, it reverts to the old, original one.

 

Edited July 11, 2023 by levster

[iXNyNe]

8 hours ago, levster said:

I am using Swag and do not see anything odd in the log. 

 

Also, I am seeing a lot of these:

Errorno app in contextOCP\Security\Bruteforce\MaxDelayReached: Reached maximum delay2023-07-10T08:27:41-0400

 

ntextOCP\Security\Bruteforce\MaxDelayReached: Reached maximum delay

/app/www/public/lib/private/User/Session.php - line 431:

OC\Security\Bruteforce\Throttler->sleepDelayOrThrowOnMax()

/app/www/public/lib/private/User/Session.php - line 580:

OC\User\Session->logClientIn("*** sensiti ... *")

/app/www/public/lib/base.php - line 1143:

OC\User\Session->tryBasicAuthLogin()

/app/www/public/ocs/v1.php - line 61:

OC::handleLogin()

/app/www/public/ocs/v2.php - line 23:

require_once("/app/www/public/ocs/v1.php")

Errorno app in contextOCP\Security\Bruteforce\MaxDelayReached: Reached maximum delay2023-07-10T08:27:41-0400

Errorno app in contextOCP\Security\Bruteforce\MaxDelayReached: Reached maximum delay2023-07-10T08:27:37-0400

Errorno app in contextOCP\Security\Bruteforce\MaxDelayReached: Reached maximum delay2023-07-10T08:22:31-0400

 

On a side note, when I go to update my personal info, the email address cannot be changed from something that I used a long time ago. As soon as I change it, it reverts to the old, original one.

 

You might try disabling the brute force app, then uninstalling it, then reinstalling it.

 

Maybe try changing your email while it's uninstalled? I haven't seen that issue before and might be something you'd need to ask about on the nextcloud forum as that doesn't sound like a container issue (and I'm not really sure how to fix it).

[nraygun]

14 hours ago, iXNyNe said:

rename /config/crontabs to something else like /config/crontabs.bak and then restart the container. it will recreate the folder. compare the files in your renamed backup folder to the files in the newly created folder. if you intentionally customized anything, you can reapply your customizations. the line it comes with should not be modified though, it would just be if you needed to add extra lines. you can delete the renamed backup folder once you've confirmed you have any customizations reapplied (or didn't have any to apply).

Thanks @iXNyNe.

The newly created crontab directory contains a single file called root that is exactly the same as the old one.

Any other ideas?

[iXNyNe]

6 minutes ago, nraygun said:

Thanks @iXNyNe.

The newly created crontab directory contains a single file called root that is exactly the same as the old one.

Any other ideas?

I believe the cron runs every 5 minutes. Can you check if you still have the error about the scheduler not running?

There was a recent change to the cron file (that should have automatically applied) to update the path of the file being executed.

[nraygun]

1 minute ago, iXNyNe said:

I believe the cron runs every 5 minutes. Can you check if you still have the error about the scheduler not running?

There was a recent change to the cron file (that should have automatically applied) to update the path of the file being executed.

Yep, still got it.

 

In addition, I see this in the logs. Not sure if it's related:

Console has to be executed with the user that owns the file config/config.php
Current user id: 99
Owner id of config.php: 1000
Console has to be executed with the user that owns the file config/config.php
Current user id: 99
Owner id of config.php: 1000

 

[iXNyNe]

3 minutes ago, nraygun said:

Yep, still got it.

 

In addition, I see this in the logs. Not sure if it's related:

Console has to be executed with the user that owns the file config/config.php
Current user id: 99
Owner id of config.php: 1000
Console has to be executed with the user that owns the file config/config.php
Current user id: 99
Owner id of config.php: 1000

 

What values do you have for PUID and PGID on the nextcloud container?

[nraygun]

3 hours ago, iXNyNe said:

What values do you have for PUID and PGID on the nextcloud container?

PUID = 99

PGID = 100

 

Should the PGID be 1000?

 

I haven't touched these settings since I first setup the container years ago.

Edited July 11, 2023 by nraygun

[iXNyNe]

15 minutes ago, nraygun said:

PUID = 99

PGID = 100

 

Should the PGID be 1000?

 

I haven't touched these settings since I first setup the container years ago.

try running this in the unraid terminal

chown -R 99:100 /mnt/user/appdata/nextclouod
chown -R 0:0 /mnt/user/appdata/nextclouod/crontabs/root

then restart the container and see if the logs still show the same message

[stiernacken]

22 hours ago, iXNyNe said:

You can read https://www.linuxserver.io/blog/2019-09-14-customizing-our-containers and use a custom-cont-init.d script. I'm not going to go into a lot of detail on this because it's kind of advanced, and we document the general concepts, but not the specifics because we can't support every customization everyone wants to do (thus the DIY approach documented in the blog post). If you can figure out how to install the extension via the custom init script you'll be all set. If not I would advise you wait until a stable release of the extension is available. It would have to show up in a branch that isn't testing and has an actual release version number like 3.19 (if it gets included there in the future). alpine very rarely adds new packages to existing releases, so it's unlikely we would see it in 3.18 or below.

 

Found the github issue (https://github.com/linuxserver/docker-nextcloud/issues/171), an tried the following script:

 

#!/bin/sh
echo "**** installing php82-pdlib (dependency for facerecognition app) ****"
apk update
apk add --upgrade -X http://dl-cdn.alpinelinux.org/alpine/edge/testing php82-pdlib

echo "**** installing bzip (dependency for facerecognition app) ****"
apk add bzip2-dev

echo "*** enable face recognition model***"
occ face:setup -M 2G
occ face:setup -m 1

 

Also added "memory_limit = 4G" in the php-local.ini

 

This is the result after restart:

Quote

[custom-init] Files found, executing
[custom-init] php82-pdlib.sh: executing...
**** installing php82-pdlib (dependency for facerecognition app) ****
fetch http://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
v3.18.2-355-g180933ca143 [http://dl-cdn.alpinelinux.org/alpine/v3.18/main]
v3.18.2-358-gfd7aff3443c [http://dl-cdn.alpinelinux.org/alpine/v3.18/community]
OK: 20082 distinct packages available
OK: 347 MiB in 264 packages
**** installing bzip (dependency for facerecognition app) ****
OK: 347 MiB in 264 packages
*** enable face recognition model***
System memory: 7.4 GB (7989993472B)
Memory assigned to PHP: 4 GB (4294967296B)

Minimum value to assign to image processing.: 682.7 MB (715827882B)
Maximum value to assign to image processing.: 4 GB (4294967296B)

Maximum memory assigned for image processing: 2 GB (2147483648B)

The files of model 1 (Default) are already installed
The model 1 (Default) was configured as default
[custom-init] php82-pdlib.sh: exited 0
 

 

Now Face Recognition App is installed and seems working Thank you very much!!!

Edited July 11, 2023 by stiernacken

[nraygun]

3 hours ago, iXNyNe said:

try running this in the unraid terminal

chown -R 99:100 /mnt/user/appdata/nextclouod
chown -R 0:0 /mnt/user/appdata/nextclouod/crontabs/root

then restart the container and see if the logs still show the same message

Yikes.

I'm a little cautious of running something with a -R option. (plus, I think you meant nextcloud not nextclouod)

 

I've never had to do this before. But then again, I was updating Nextcloud manually at the command prompt before they included updates in the container.

 

Before I do such things, has something changed with the container where I have to do this?