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