iXNyNe

The version of xz in our latest release of digikam (and our kasm arch base image) is 5.6.1-3 which has been patched according to https://security.archlinux.org/AVG-2851

https://info.linuxserver.io/issues/2024-03-29-cve-2024-3094/ Tldr: lsio images are mostly unaffected. Updating to the latest images is recommended as a precaution.

Just as a clarification: I'm not advocating to require 2fa for all logins. Making it available for those who want it would be ideal. Requiring it when using https://connect.myunraid.net/ to allow remote access would also be sane.

https://connect.myunraid.net/ (an official unRAID product) seems to contradict the constant user posts on this forum saying not to expose unRAID to the internet. The entire premise of https://connect.myunraid.net/ is to expose and manage your unRAID systems remotely. This exposes the unRAID web login form to the internet. Since this seems to be officially supported behavior it would make sense for there to be a greater care for security. Another good example would be strengthening the default SSH configurations to require keypairs in order to connect to SSH by default. SSH in unRAID can be configured for proper security with SSH, making it entirely safe to expose to the internet (at least as safe as any VPS you would access via SSH), but these safer configurations are not the default. The web UI has no such configurations to improve security, such as requiring 2fa. It's fair and reasonable to tell a user that if they are not educated on the risks of exposing their system to the internet that they should not do it, but it's also fair to point out that unRAID's web UI login could be improved by adding 2fa. unRAID's login seems to be php based, and there are a handful of very good composer packages that make implementing 2fa very easy. Hopefully unRAID considers this.

Again, I am typically the one making those changes, and usually testing them before they are released to the public. For the most part, if you haven't modified any of your .conf files, you can just delete them all and restart the container and they will be replaced with updated copies. We do generally try to include some automated migrations/adjustments to nginx confs when possible if there's a breaking change. If it's not a breaking change (ex: your setup should continue working without updated confs) we log a message in the container logs to let you know you should update them manually. There are also scenarios where an automated update to .conf files is not possible, but the logs will still show the warning, so I recommend checking the logs if you have any issues.

You can install exiftool via https://github.com/linuxserver/docker-mods/tree/universal-package-install Basically adding two variables to your container. pinging @SDEN for visibility.

You likely also need to update your nginx files. Specifically: /config/nginx/site-confs/default.conf This line: https://github.com/linuxserver/docker-nextcloud/blob/3accfcac32414f739ef312281d256a3fc9a47c6f/root/defaults/nginx/site-confs/default.conf.sample#L29C31-L29C31 would need to be adjusted to match your max upload setting in php. you may also need to update the timeout line right below it. After making the changes, restart the container.

This is really up to you. Personally I run the latest tag, but I am uniquely positioned to be aware of incoming changes (and possibly responsible for some of them). We do what we can to keep the releases usable with the latest tag and account for upgrade paths, but it's not always possible. Nextcloud was a unique case where prior to version 27 our image did not handle updating nextcloud itself, it only updated the underlying dependencies. With the release of our image for nextcloud 27 and above, we now include the nextcloud application inside the container, and updates SHOULD run smoothly if you use the latest tag and update when updates are available. It's a good practice to be more in control of your updates and pin tags and update manually, if for nothing else then to be aware of when an update is being applied rather than waking up to an overnight automatic update breaking your instance. The best way to track updates is by subscribing to release notifications on https://github.com/linuxserver/docker-nextcloud

You should be able to run docker exec -it nextcloud occ preview:generate-all -vvv >> /mnt/user/appdata/nextcloud/preview_generate.log 2>&1 You do not need to specify the user, the php command, or the path to the occ application. We built an alias in to the container to handle all of that.

Do NOT update nextcloud by clicking the update button from the nextcloud admin status page. Do update nextcloud by telling unRAID to check for and apply updates to your container.

There is nothing to push. https://github.com/linuxserver/docker-nextcloud/issues/272 has the explanation.

Delete /config/www/nextcloud/index.php and set your image to lscr.io/linuxserver/nextcloud:version-26.0.2 and let the container restart. That should recreate the files it says are missing. Then you can rerun the updater.

if you haven't intentionally customized the root cron file in your config i would suggest deleting it and restarting the container. This will recreate the default file with the latest changes.

I've recently started using tailscale and the unraid plugin for it with SSH enabled. It seems to pretty much solve both the multi-user and the open SSH port issues at once for me anyway. Specifically the multi-user aspect just means letting multiple different users login to SSH as root without giving out a password or managing keys. That might not be what everyone is looking for, but it might solve the needs for some. I also do still use the unraid connect plugin, and I wish it didn't require an open port, but it doesn't bother me enough to not use it.

Switch your image to lscr.io/linuxserver/nextcloud:version-26.0.2 then run docker exec -it nextcloud updater.phar # if successful, repeat until there are no more updates then switch back to lscr.io/linuxserver/nextcloud:latest

Set your image to lscr.io/linuxserver/nextcloud:version-26.0.2 run in the unraid terminal (not the container terminal) docker exec -it nextcloud updater.phar # if successful, run it again until it says there are no more updates let us know the results

Sorry for the delay. I would delete /config/www/nextcloud/index.php and set your image to lscr.io/linuxserver/nextcloud:version-23.0.4 and restart the container then run docker exec -it nextcloud updater.phar # if it succeeds, run it again until it says no updates Edit: I see there's a newer reply from you after this one I quoted, and I don't think these instructions are what you need (yet). It looks like your database needs a repair of some sort. I don't have specific instructions for that, but some commands you could try docker exec -it nextcloud occ maintenance:repair docker exec -it nextcloud occ db:add-missing-columns docker exec -it nextcloud occ db:add-missing-indices docker exec -it nextcloud occ db:add-missing-primary-keys If none of those fix it, it could be something you'll have to fix with the sqlite command (and google the error message).

You can use lscr.io/linuxserver/nextcloud:version-26.0.2 Go to CA as if you were adding the app for the first time and it'll bring back your original container with your settings and you can set the image to lscr.io/linuxserver/nextcloud:version-26.0.2

I would try running docker exec -it nextcloud occ update And see if it still throws a fit. Also, try accessing the web interface and check the admin status page for any errors or recommended commands.

Prior to 27.x our image required you to manually update nextcloud. You should be able to run the updater.phar command listed in the article without changing your image to get updated. You may need to run it multiple times until it says there are no available updates. Once you get to that point, check which version you are on and follow along the article. If you have any issues, post logs here.

The current latest image should be lscr.io/linuxserver/nextcloud:version-27.0.1 If you set your image to that it should stay pinned until you change it. You can track when new versions are released by subscribing to release notifications at https://github.com/linuxserver/docker-nextcloud Note that we do sometimes update the version tags, so there may at times be updates available even if you pin the version, but it would be for things like OS dependencies, and not for nextcloud itself. If you want to pin to exactly how things are running right now and not get updates for underlying things like OS or package dependencies you can use lscr.io/linuxserver/nextcloud:27.0.1-ls259 That tag matches exactly with the release names from https://github.com/linuxserver/docker-nextcloud/releases and will be static builds we do not update/replace over time (you would have to change the tag to a new tag to get an update).

Switch to the image for 26.x and try running the updater

The "fatal: unable to exec php7" error is from cron and can be ignored for now. I would continue running the image for lscr.io/linuxserver/nextcloud:version-24.0.12 and delete /config/www/nextcloud/www/index.php and restart the container. Then delete /data/updater-<randomstring>/.step and run "docker exec -it nextcloud updater.phar"

It could be baked in, but nextcloud's official image doesn't do it, and our general stance is we don't want to in case it's destructive. this should be done manually after backing up your database and appdata. That being said I haven't had any issues with doing it, but that doesn't mean nobody ever has.

The built in updater in the web UI is no longer supported when using our docker image (I believe the official image from nextcloud also doesn't support it). The correct way to update nextcloud is to update the container image.