JonathanM

Possible, yes, but not likely. Relatively lots of programming and debugging for very little benefit. The existing method is proven to work in any case.

The functionality is the same, the wording has been changed to better clarify where the files are initially placed and where the mover puts them.

Click on the link in his post.

Sure! Replace and rebuild 2 of the smaller drives, copy the data from the 3rd drive to the 2 new drives using whichever method you feel comfortable with, Unbalance is one option. Once the data from the drive to be removed is safely on the other array drives, set a new config, remove it, and rebuild parity with the remaining drives.

Yeah, automation only works if all the prerequisites are met. When you step outside the box, you have to learn how to do this kind of stuff manually. It's not really that difficult, just have to step through each bit and follow it back to determine where the values came from, and override with your specific values. IMHO it's pointless to push usenet through a vpn if the connection is already encrypted. The usenet provider knows who you are, the ISP can see the amount of traffic but can't see the content, which is the same situation with any encrypted traffic. The only reason vpn is useful for torrents is anybody in the torrent group can see everyone else's IP as well as the content. Remove the knowledge of the content with the SSL pipe to the usenet provider, and there is no quick way to analyze you like there is with torrents.

In the conf file that has your nzbget section, what value is in the proxy_pass line?

What address are you using in the SWAG config? You should be using the address that works locally.

Bottom line, Nextcloud is different.

BTW, the general broken nature of nextcloud's update process, i.e. needing to do multiple manual steps to successfully upgrade, followed by taking care of all the security and setup action items on the administration overview page after the upgrade is complete, that whole complicated mess is WHY lsio does NOT automatically upgrade the nextcloud app in their container updates. Nextcloud is a complicated beast with many inter-operating parts, it needs care and feeding to stay healthy, you can't just fire and forget. The closest you will get to that is set a fixed tag for the container, then only update when you are willing to take the time and step through the process manually.

Go to this page https://download.nextcloud.com/server/releases/ Find the release zip file you need, probably https://download.nextcloud.com/server/releases/nextcloud-25.0.7.zip Open the file, extract the shipped.json out of the core folder and copy it to appdata/nextcloud/www/nextcloud/core then rerun the updater.phar

If you don't want to update on lsio's schedule, use a fixed repository tag. That way you can update when you want. Using the latest tag sometimes requires extra work to stay running.

If you edit the nextcloud container, what is the exact content of your Repository: line?

Possibly you could use Nextcloud, but the standard setup would expose your IP. I think a cloudflared url could hide the IP, but I've not personally tried that. Most any file sharing setups will expose the IP of the source, that's kind of how the internet works.

Unfortunately licenses can not be transferred, so you will need to get your friend to contact support.

Shouldn't be necessary, it's just a troubleshooting step to see if the array stops in a reasonable period of time. There is likely something keeping the array from stopping, causing the shutdown to kill the array prematurely, triggering a parity check on startup. If that's the case, you need to figure out what is keeping the array from stopping.

Try stopping the array before hitting the shutdown GUI button.

Assuming you assessed the situation correctly, parity swap is what you need. If any of your other drives isn't able to be read during the procedure you will lose data, so you really want to be sure of what are doing. If you're at all hesitant, attach your diagnostics to the next post in this thread so someone can look things over for you.

Have you tried deleting the network.cfg and letting Unraid recreate it?

Not sure what you mean, I don't see anything out of the ordinary. Maybe this is throwing you off? https://docs.unraid.net/legacy/FAQ/understanding-smart-reports#1-raw_read_error_rate

Exactly. Never update the container without first checking the Nextcloud version inside the app. The two events will seldom if ever overlap, the app will typically update much less often than the container, so many times you will still be up to date with Nextcloud when the container updates. The issue comes when people ignore the app updates for months and automatically update the container.

When using this container for Nextcloud, YOU are responsible for keeping the Nextcloud app up to date. The updates for this specific container NEVER upgrade the application, only the surrounding support files. If you don't want to be surprised by this, set the docker tag to a specific version instead of latest, so things don't get updated until you update both the application and the container version manually. There are other Nextcloud container implementations that may approach this differently, you may wish to investigate how they handle updates and switch if it fits your needs better.

Port mapping only applies to bridge mode. When a container has a different IP address than the host, mapping is not used or needed, all ports are open and the listening port(s) are directly controlled by the application(s) in the container.

Frequently discussed in the nextcloud support threads. Caused by failure to update the application inside the container before updating the container, the container OS gets too far ahead of the nextcloud program version.

Take this as a reminder to keep your flash drive backup up to date.

I believe you are correct, maintenance mode from step 2 until step 7 would be a good idea. In step 3 you need to assign it to the array so Unraid detects the step 6 removal and starts the emulation in step 7. @trurl@JorgeB, anything I missed? I personally don't have any Unraid encrypted file systems in place so I may have missed something there. Possibly may need to set the file system to encrypted instead of auto on each of the data slots? It wouldn't hurt to have a test drive or two, even old ones, to help validate the trial is working well before you commit to recovery and start attaching the real data disks. Starting completely over with new everything means memtest and at least some burn in hours before you should trust it. It would really suck to find out the new system mangles data while trying to recover a failed disk. I would really work over the trial system in step 1 to uncover any gremlins. After you are satisfied the new system is stable, you will need to set a "new config" to remove the test disks and prepare for step 2 and on. Don't rush through any of this process. I fully expect you to pound on the trial for several days before moving on, preferably starting off with 24 hours of memtest, I'd download the latest free version from https://www.memtest86.com/ and run it.