explosionhole

I am getting errors for 2 domains. The containers behind them are no longer running. The certs have also expired. I posted a support ticket on the Lets Encrypt forum (https://community.letsencrypt.org/t/errors-in-npm-log-files/244662/2), but the advice was this is an issue with how NPM handles revoking of expired certs. I deleted these 2 affected proxy hosts from NPM, and also in the Certificates menu, I deleted them. How do I remove them from my NPM config, so no more certbot requests are made?

Yeah, I've seen the internal container handles version updates very well in the past. The DotEnv (`.env`) file is only a different method to pass in environment variables, so no reason it should not work as is(?) So long as the same variables (and syntax) are used, I'd expect it to work. Unless v12 adds new or changed ENV VARs... Or maybe it does a filesystem check of the DotEnv file. Sorry, not actually tried any of this. But if you got a running version that would suggest the config's work... What other tests / checks are necessary to upgrade from a "beta" status?

Thanks for the contribution, @dglb99. For the purposes of this discussion, why can't you update the tags? Who has tried it? What was their outcome? I assume a full data backup should allow to either: - restore the data into a new container running an older container version, or - duplicate the backup data, and create 2nd container at the new version. Then delete the copied data if everything is working I have had no time to even start or try...

I followed the Seafile documentation to backup the folder structure and MariaDB's (cc_net, seafile_db, seahub_db). I did this manually, it could easily be scripted. I don't do this, as my Unraid backup process simply copies this live data folder structure with Duplicati (as a VM) and also a User.Script with the equivalent MariaDB `mysqldump --all-databases` command. Then I clicked into my `Seafile-Official` container item, toggled to the `Advanced View` (top right of the page), then edited the `Repository` value to: seafileltd/seafile-mc:11.0-latest Scrolled to the bottom, and clicked Apply. This worked, and downloaded the latest version for v11, which is `11.0.13`. Reading the Seafile docs again, the container itself contains the internal upgrade scripts, and watching the container's logs when it first upgraded, I saw it pick up the appropriate upgrade script. I also note the Unraid Docker page now shows this container as `up to date` again. So it is just a change in the tagging text that has occurred. This same behaviour will occur when upgrading between MAJOR versions. v12.0.10 is available, but it seems on the forums there are some known issues which should be addressed in v12.0.11, which I will wait for. When I do this, all I need to do is update the above Repository line to the equivalent for `12.0-latest`.

Glad you are on the Seafile story - I have used for many years, and think it offers many great features. My libraries are now over 120GB, but I do not focus on huge files for this purpose. Mostly PDFs, JPGs, PNGs. The largest files tend to be media, which I continue to use more basic SMB, even NFS, shares. My experience, the desktop clients are most reliable, especially with huge files. You're welcome to join in on on this thread, but it is a bit different. More Docker shenanigans, swapping between repo images, by only repointing the container to the same underlying storage / file structure. But also ensuring that as container versions are upgraded, Seafile's internal update scripts / configs are applied, if this is still relevant. There is a whole backup/restore function in their documentation, but I don't think it resolves my issue with switching between image repos, except (I guess) if I initially swap to exact same server version, do my restore, then upgrade that container image.

Running a Portainer container, I can see this Image. What would occur if I manually pulled the latest image? Then restarted the container? Does Seafile internal upgrade mechanisms to support this? I recall in the past they had combinations of Shell scripts for version upgrades when I ran it before Docker. Second, what would happen if I just edit this container's config to point to the alternate `seafileltd/seafile-mc` repo image? Will it destroy the existing data?? Has anyone tried this? I guess the environment variables passed around would need to be validated?

When I installed my Unraid system, I made the choice for numerous Docker containers. One of which was Seafile, that I had previously used in a non-Docker install. The migration was considerable, and ultimately I used a new 2nd instance, then replicated data manually between them. I do not want, nor see the need to, repeat this effort. I chose the then-`Official` Seafilie-Official image offered by `piranha771`, which I think is now no longer being maintained. In the Apps section, it displays "Not Available" for updates. It is currently running v.11.0.9. I have posted an `Issue` on their Github repo, though I do not expect any follow up. This repo is pulling from `seafileltd/seafile-mc`, which I see on Docker Hub was updated this current month (March 2025). Why can I not update my container? There are updates available. The alternative Seafile containers (listed below) also use the same repo. How are they able to keep updated? Is this some unique Unraid thing? @Fantucie --> Image is simply called `Seafile`, uses `seafileltd/seafile` @dglb99 --> Image is called `seafile-10` (pulling image `seafileltd/seafile-mc:10.0-latest`) and `seafile-11` (pulling `seafileltd/seafile-mc:11.0-latest`) Finally, can I "swap" from the current `piranha-771` image to any of these alternatives just be repointing my local files? I run MariaDB in its own Unraid container, that I provide the config for in the existing container config, so should be easy to replicate. No clue about file structures though!

Yes, I saw this recently as well, but need to read more around the upgrade process, known issues, etc, before attempting it... I have what I would expect is a typical implementation, but I obviously have my configs and usage to be wary of, such as Tailscale community script / plugin and a number of Docker containers. Any insight how safe / mature this is would be appreciated, but I also expect everybody's mileage to vary...

Thanks @Frank1940 - ISOs and Domains are empty. They were default shares when I installed Unraid originally. I am using 15% of that 1TB Cache SSD. The server is fairly static now, with the essential configs already in place. However, I obviously do tinker with new containers over time, such as this NextCloud exploration.

Today I was looking to install NextCloud. The Info page stated to use `/mnt/cache/` for the underlying MariaDB. In turn, I looked at my current MariaDB config, but it is actually set to `/mnt/appdata/mariadb-official/data`. I also checked the `appdata` share, and it is set Primary to `Cache`, but I also have Secondary to `Array, High-water` and the Mover action set to `Array to Cache`. I also note that this directory exists, but is NOT on the `/mnt/diskX/` equivalent locations: `/mnt/cache/appdata` What have I configured?!? Do I need to set `appdata` Secondary to `None`? Do I need to manually run any data moves (and what sequence should be used with active processes? How do I update the MariaDB container config? Can I simply update the `Data` path to `/mnt/cache/mariab-official/data` and it will start using the Cache with no other effort or tasks required? I have seen some posts on similar topics, but they occur from multiple years ago and older Unraid versions, but also I have my specific diagnostics attached for my use-case. Tower Diagnostics Mar 02 2025.zip

After a good sleep, I finished off the user scripts section, to place the binary into the `/usr/bin/` directory and giving it execute permissions. So from the Unraid terminal, I can now execute the `docker-buildx` binary and with no parameters, I get the basic usage instructions. Final question from me is if I can do a symlink, or similar, so that `docker build ....` would be the same as executing `docker-buildx`? If I follow online guides, or pull from Git repos, etc, I expect they will mostly us the former format.

thanks for the help. and kindness. I found the Boot Device section and turned this setting on. Uploaded the `docker-buildx` file. Resuming tomorrow - gone 11pm here.

No worries, we were just mere connections apart. so I tried this section, there were no items. if I add a new one, I don't see my boot drive as an option

why does your response need to be so confrontational? equally, the poster's instruction did not provide this additional snarky "fact". I am genuinely interested in a technical query. please be (according to your scale) kind. And for posterity so others can find this info. Where is this set? Is there a description or reason for it? am I looking in the Settings panel?