iXNyNe

The last 50-100 lines is probably enough.

can you post your container logs?

A more permanent fix for the integrity check issue is in the works now. I'll update once it's released. Until then, it shouldn't cause any functional issues to ignore the integrity check error. For anyone who's nextcloud instance isn't working otherwise, again I'll try to reply here quickly, but you may get quicker support in the LSIO discord (where there's other team members available as well).

from the unraid terminal run docker exec nextcloud touch /config/www/nextcloud/config/needs_migration or if you terminal directly into the container, just touch /config/www/nextcloud/config/needs_migration then restart the container That should force the init to reinstall the default files.

LSIO tries pretty hard to notify about important changes: https://github.com/linuxserver/docker-nextcloud#versions (every repo has a section like this) https://github.com/linuxserver/docker-nextcloud/releases/tag/27.0.0-ls252 (every release has notes like this, and on GitHub you can subscribe to email notifications when releases happen) https://info.linuxserver.io/issues/2023-06-25-nextcloud/ (if there's any big or breaking changes we usually post a notification to our info site with more detailed instructions like this post, the info site also has an RSS feed and posts also are sent to a dedicated notification channel in our discord) Auto update is definitely not the safest thing to be doing, but we understand how common it is and try to mitigate as much as we can. Nextcloud was a special case, because prior to this update the installation files were stored on your /config volume and mostly untouched by the container without manually running the occ command to upgrade. This however lead to the container dependencies like PHP updating over time with new releases of the container, and the installed version of nextcloud not being updated, and sometimes the installed (outdated) version of nextcloud would not be compatible with the current dependencies in the image. To solve this, we've build the application itself into the container and cherry picked only the files and folders that need to be persistent to remain in the /config volume. In the future, updating the container should automatically update nextcloud itself, along with any dependencies like PHP. All that being said, LSIO does still recommend pinning a specific version tag such as lscr.io/linuxserver/nextcloud:version-27.0.0 and applying updates manually by simply changing the version at the end. A proper backup and recovery plan is also important.

Please read https://info.linuxserver.io/issues/2023-06-25-nextcloud/ It should have all the info you need. If you still have issues feel free to reply here, or message on the LSIO discord (response time might be faster there).

The major version (the first number in the version before the decimal) is all that you need to worry about. Using lscr.io/linuxserver/nextcloud:version-25.0.4 should be fine, even if your install is 25.0.3 or 25.0.0 The key thing you missed in the tag is the prefix: version-

Changing the image forces docker to recreate (not just restart) the container. That's the trick to solve some problems, such as the core files inside the container (they would not exist if you recreate the container). It doesn't even have to be the specific image I listed, and you don't have to switch back to the latest image either. You can pin any tag you'd like, and in fact LSIO recommends pinning images whenever possible to prevent surprise auto updates.

deadlocks seem like a bad thing in the logs to recreate the container, just swap the image like i mentioned in my last post, then swap it back also, check the container logs for anything that might need attention the web admin status page might have a database upgrade command that needs to be run that might solve the deadlock issue, but i'm not positive. that could legitimately be a spec issue.

The files were present in a previous version of nextcloud, and are no longer needed in the current version. I am unsure if nextcloud has a way to automatically remove these files, but it doesn't appear to (if it does I'd be happy to implement it in the lsio image). If you leave the files, the warning will continue to show in your admin page. There's no functional issue with leaving them there. Just the annoying warning. As far as your path, that should be correct, just keep in mind the files are inside subfolders for each app. So the photos folder may have a number of files inside it that need to be removed, and another folder might have a different list. The warning shows all the files and in which subfolder, but it doesn't provide the full path. As for the core files, it actually looks like those are no longer in a user accessible location, but you could recreate the image and those should be fixed. The easiest way to recreate the image it switch the image to lscr.io/linuxserver/nextcloud:version-27.0.0 and then back to lscr.io/linuxserver/nextcloud

You can delete these files. They should exist in /config/www/nextcloud/apps/ and then inside subfolders for each of the apps listed (core, cloud_federation_api, etc).

This is expected. Please read https://info.linuxserver.io/issues/2023-06-25-nextcloud/ tldr; no more manual updates

Does the Update containers after backup feature require CA Auto Update Applications to be installed?

https://github.com/linuxserver/docker-fail2ban Is now available in CA, and comes with config examples to protect unRAID's sshd and web GUI.

I decided to do something about it. While I don't have a solution to run fail2ban directly on the native OS, I am now successfully running a docker container capable of applying iptables bans at the host level and I am protecting unRAID's web GUI and SSH (and other things running in other docker containers). I plan to share this project as an lsio image in the near future. I have everything functional complete and I am working on documentation. I'll try to remember to reply here when I have a proper release available.

I'd like to see general TOTP support. Duo supports TOTP, so users can opt to use Duo if they want, or use any TOTP app they prefer.

I don't have any knowledge about how logins are handled with the web UI, but I believe unRAID's web UI is written in PHP, and maybe something like this could be used https://packagist.org/packages/pragmarx/google2fa-qrcode I have implemented 2fa in some other projects using that library. It's been very nice to work with.

Duplicate of

I mentioned in discord over the weekend that I keep seeing suggestions against exposing unRAID to the internet in any capacity, but the My Servers plugin comes with a built in option to do exactly that (expose the web UI to the internet to allow remote access), and exposing SSH to the internet can be done very safely and easily if you prohibit password login as root via ssh. Either way, it would be insanely beneficial to have fail2ban natively on unRAID, either with some standard configurations for SSH and HTTP/HTTPS, or with some easy to enable examples and instructions. SWAG is great, I use it, I contribute to the project, but native support would be greatly appreciated.

/etc/ssh/sshd_config Contains a line that reads: PermitRootLogin yes And also a commented out line that reads: #PermitRootLogin prohibit-password The official manual at https://www.openssh.com/manual.html links to https://man.openbsd.org/sshd_config and the section relevant to this request is https://man.openbsd.org/sshd_config#PermitRootLogin where it is documented that prohibit-password is the default behavior. The sshd_config file currently shipped defines PermitRootLogin as yes. Allowing password login as root can be viewed as convenient for users, but requiring the use of SSH keys to login as root should be considered a significant security improvement. The unRAID web GUI has a very easy and convenient way to add and manage authorized_keys for the root user, and it can also be accomplished by editing: /boot/config/ssh/root/authorized_keys It would also be a nice touch to include some kind of an informational link in the web GUI next to the "SSH authorized keys" setting when editing the root user (maybe in the tips shown when enabling the Help information) that informs the user how to generate SSH keys. It probably makes the most sense for this to be documented somewhere like https://wiki.unraid.net/Terminal_Access#SSH (just include information about using ssh-keygen similar to https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent and information about adding the key to the root user) and use that as the link in the GUI, possibly include the information directly in the GUI help tips. Some extra information just to be clear about why I'm opening this request: Making the above modification (specifically just remove the "PermitRootLogin yes" line from /etc/ssh/sshd_config and the behaviour will fall back to "PermitRootLogin prohibit-password") does not disable logging into SSH as root, it just requires using an SSH key to login as root and (as the default value implies) prohibits using a password when logging into SSH as root. I am aware that I can create my own file at: /boot/config/ssh/sshd_config Either by writing it from scratch or copying from /etc/ssh/sshd_config and modifying what I need. This is noted at https://wiki.unraid.net/Manual/Release_Notes/Unraid_OS_6.9.0#SSH_Improvements but I feel this change would be a valid improvement to default SSH security provided by unRAID. Users can opt to use /boot/config/ssh/sshd_config as a way to re-enable logging in as root with a password. I have tested the modification by copying /etc/ssh/sshd_config to /boot/config/ssh/sshd_config and removing the "PermitRootLogin yes" line and running "/etc/rc.d/rc.sshd restart" and then confirming I am unable to login to SSH as root using a password but still able to login to SSH as root using a key. Edit: I would also be interested in discussing additional security enhancements to the default SSH configuration, and I will cite https://infosec.mozilla.org/guidelines/openssh (up to date as of 2022).

It actually sounds like you've managed to get through the creation of the USB (using the manual method) and you're now having an issue with the GUI when booting. I'm no expert, but I wonder if you could try the non-GUI boot option and then access the web UI over the network via the server IP? If so, you should be able to pre-clear from there (I believe you would be looking to install CA and then the preclear app).

I don't disagree with the points you're making, but does your system not have USB at all? The USB port on your server does not have to be 2.0. The USB creator is where the problem is. If you buy a brand new USB 3.0/3.1 flash drive and use the manual method to setup the flash drive you can plug it into any USB 2.x/3.x port on your server without issue. Booting from something other than USB (ex: using a nvme as the boot disk) is another issue entirely. And I'm completely on board that this would be lovely to have, but I wouldn't count it against unraid in the same capacity as the USB creator issues.

Trust me, I'm but defending the USB creator, but honestly if the manual instructions are too much effort (format and label a flash drive, download and unzip a file, run a bat file) then you're not going to have a good time running a server regardless of what OS it is. Unraid probably should deprecate the USB creator and promote the manual option to the recommended method. The USB creator will increasingly leave a bad first impression as USB 2 becomes less common over time.

The USB creator seems to be left untouched with regards to this issue. Don't let that discourage you from using unraid. The manual install works fine https://wiki.unraid.net/Articles/Getting_Started#Manual_Install_Method