iXNyNe

Running through a checklist first (trying to recap your previous posts, i apologize if i've mixed anything up while helping others as well) - You currently have nextcloud 27 listed as the version in /config/www/nextcloud/config/config.php (on your array this is probably /mnt/user/appdata/nextcloud/www/nextcloud/config/config.php ) - You are running the latest image/tag - You are seeing php errors in the nextcloud logs Assuming all of the above is correct (if not, reply and let me know before you do anything else) I believe the next step is to rename /mnt/user/appdata/nextcloud/www/nextcloud/apps folder to apps_backup or something, and then restart the container. It should create a new apps folder with only the default apps installed. Check if nextcloud seems to be for the most part working (maybe missing some functionality you need from apps). If it seems to be running stable, then you would compare the list of apps folders in the newly created apps folder and in your backup folder and manually reinstall any missing apps. I would do this one at a time to confirm each one you reinstall doesn't cause errors.

Based on your last two posts, if you've got nextcloud upgraded to 27, and the container set to latest, you could try renaming your apps folder and restarting the container. This would recreate a new apps folder with only the default apps. If things stay stable, you can reintroduce your apps one by one until you find which one might be causing the issue.

I would stop the container, rename your nextcloud appdata folder, rename your nextcloud data folder, set the image to the latest tag, and start the container. Then go through the first time install. Once that's done, re-add your files from your data folder by uploading them again (don't just put them in the new data folder, I don't know if that would even work). As for preventing this, I strongly recommend making routine backups. The appdata backup plugin should work fine, but if you have a preference for another option you can do that as well.

Post your container logs.

Try updating those configs and restarting the container. Each config has a *.sample counterpart in the same folder as the outdated conf. You can compare them and update your config with the changes from the new config. If you didn't customize the file yourself, you can delete the file and restart the container.

I have not seen any container update trigger a parity check. As for the config update, those are normal, it happens whenever we (LSIO) update those files. We don't automatically replace your file, because you may have customized it. If you didn't customize it, you can just delete the file and restart the container and it'll be recreated with the updates.

I think you're going to have to restore your appdata from a backup. If the version.php and config.php are empty files you won't be able to recover. The only other option is a clean install, but you would lose all of your nextcloud data.

For any lsio image you can subscribe to github release notifications for the individual repo that corresponds to the image. Ex https://github.com/linuxserver/docker-nextcloud Use the watch button, choose custom, select Releases.

On your array should be /mnt/user/appdata/nextcloud/ (the container would see this as /config, and you may have changed your paths depending on your array and cache disks) From there you should see a www folder, and inside that a nextcloud folder. So /mnt/user/appdata/nextcloud/www/nextcloud/ (or /config/www/nextcloud/ inside the container). Can you post a screenshot of the file list inside that folder? The version.php file should be right there in that folder if you have not yet updated to the latest image (the latest image removes it, not a problem, just want to know where we need to start). There should also be a config folder with config.php inside. If this file is empty, you will need to restore from a backup. Restoring the docker.img isn't what we need, you'll need to restore from a backup of your appdata. If you don't have a backup, it will be difficult (if at all possible) to recover.

Start with looking in /config/www/nextcloud/config/config.php look for a variable named "maintenance" and if it is set to true, change it to false. If it does not exist, that's fine. look for a variable named "version" and post the version here in a reply (wanting to be 100% sure where you're at) I will advise on additional steps after that.

You could try the following: - stop your nextcloud container - use SSH or the unraid UI to access the terminal for unraid itself - use docker command line to run a separate docker container for nextcloud, specifically using the image you need, but point the config and data volumes to the same places your live container uses - use the CLI updater to get updated to version 26 or 27 (may require updating as far as you can and then stopping the temp container and making a new one with a newer image) - stop and remove the temp container via docker CLI - start your nextcloud container in unraid like normal That should get you where you need to be

And there is no option to login (instead of register)? My next suggestion would be to check the config.php for a version. Post the version from your config.php here along with your container logs (those really help narrow things down). We may need to change to an older image to try and get things working again, and possibly might need to restore the config, the data mount, and the database (but I won't be sure what's needed without more info). p.s I can only read english unfortunately, so I may have to ask for translations

does your config.php still have the correct database credentials and connection info? can you post your container logs here?

https://info.linuxserver.io/issues/2023-06-25-nextcloud/ You should not need to restore from backup. You will need to change your image (as instructed in the post I'm linking) and follow the steps to get updated. Future updates shouldn't require manual action.

That's definitely not the most up to date cron file. It should look like this https://github.com/linuxserver/docker-nextcloud/blob/master/root/etc/crontabs/root

The container comes with its own cron, you shouldn't need a user script. If you look in /config/crontabs/ there should be a file called root, and I'm guessing it has an incorrect path in it. You can delete the file and restart the container and it will recreate the file with the correct path.

Re: changes from deleting the nginx confs At the top of each file is a link to the list of changes applied to the file. It's usually minor functional or organizational changes with these. Re: integrity check extra files You can try the test image I posted above (it should take care of the files for you) or hang in there for the next stable release. The files don't cause any issue other than the warning, and they will be cleaned up automatically with the next release (or using the test image). Re: header warning If you're using nextcloud behind a reverse proxy you should configure that setting in your proxy rather than nextcloud. I advise looking up what hsts is and how it works and ensuring you can access nextcloud via https before turning hsts on. Otherwise, ignore the warning. It's harmless.

Staying locked is smart, but if you prefer the bleeding edge you can go back to the latest tag. If you're locked there won't be any surprise updates. Not every update will work perfectly even if you're locked (always check the changes logs for important changes), but using latest could mean a breaking change is applied at a time when you're less prepared to handle it.

The latest test image is lspipepr/nextcloud:27.0.0-pkg-34240624-dev-d151fd013f86933409d88dbdd26222232842031f-pr-325 It has a bunch of small fixes and tweaks, among them the integrity check extra files should be resolved. Shouldn't be long before this is released as lscr.io/linuxserver/nextcloud:latest for those who would like to wait.

The integrity check message shouldn't cause any functional issue and should be resolved in the next release. If you're interested in testing the fix before it is fully released see my message above.

If anyone wants to test the fix here are instructions https://github.com/linuxserver/docker-nextcloud/issues/324#issuecomment-1608555412 I would just ask that you let me know your results. Right now I'm just waiting for confirmation.

Check your container logs and post them here.

Follow the instructions here to get your nextcloud running https://info.linuxserver.io/issues/2023-06-25-nextcloud/ Once that's done, if you prefer automatic updates, the post mentions using the image without a tag. Then anytime you update the docker container it should update nextcloud (no more manual command updates). If you prefer manual updates, pin a tag for the current version and change the tag when you want to update.

That's the correct log. At the bottom it mentions two nginx config files you need to update (the samples in the folder with those files are the updated version). If you didn't customize those files yourself you can delete them and restart the container and they will be recreated.

Sorry, this looks like the log file, not the container log. You should be able to run docker logs nextcloud From the unRAID terminal