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?

why don't I have a /flash directory on my system?

Thanks @EDACerton - I had provided these files when I made the original post on Friday 09:46, but I will attach another downloaded file made just as I reply to this message. Tower-tailscale-diag-20240520-084545.zip

Yes, I updated yesterday ahead of making this thread.

I am having networking issues, which have occurred after updating get Tailscale plugin earlier this week. Unraid is my home server, IPv4 192.168.1.1 Docker is running within this server, which I have not directly configured any network / DNS settings, but had worked without issue. Running containers have port mapping so be accessed via the local network, which I expect to use the above 192.168.1.1 address. I also use the Nginx Proxy Manager (NPM) container as a front-facing reverse proxy for incoming connections to LetsEncrypt SSL certs. I cannot complete the creation of a new NPM Host. The direct log file contains: [5/17/2024] [9:30:07 AM] [SSL ] › ℹ info Requesting Let'sEncrypt certificates for Cert #26: sab.redswitch.co.uk [5/17/2024] [9:30:07 AM] [SSL ] › ℹ info Command: certbot certonly --config "/etc/letsencrypt.ini" --work-dir "/tmp/letsencrypt-lib" --logs-dir "/tmp/letsencrypt-log" --cert-name "npm-26" --agree-tos --authenticator webroot --email "[email protected]" --preferred-challenges "dns,http" --domains "sab.redswitch.co.uk" [5/17/2024] [9:30:07 AM] [Global ] › ⬤ debug CMD: certbot certonly --config "/etc/letsencrypt.ini" --work-dir "/tmp/letsencrypt-lib" --logs-dir "/tmp/letsencrypt-log" --cert-name "npm-26" --agree-tos --authenticator webroot --email "[email protected]" --preferred-challenges "dns,http" --domains "sab.redswitch.co.uk" [5/17/2024] [9:30:10 AM] [Nginx ] › ⬤ debug Deleting file: /data/nginx/temp/letsencrypt_26.conf [5/17/2024] [9:30:10 AM] [Global ] › ⬤ debug CMD: /usr/sbin/nginx -t -g "error_log off;" [5/17/2024] [9:30:10 AM] [Nginx ] › ℹ info Reloading Nginx [5/17/2024] [9:30:10 AM] [Global ] › ⬤ debug CMD: /usr/sbin/nginx -s reload [5/17/2024] [9:30:10 AM] [Express ] › ⚠ warning Saving debug log to /tmp/letsencrypt-log/letsencrypt.log Some challenges have failed. Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /tmp/letsencrypt-log/letsencrypt.log or re-run Certbot with -v for more details. I have attached the Tailscale plugin diagnostics as well as the letsencrypt-log file (obtained from within the NPM container). If I open Unraid's console: "nslookup tower" (the Unraid hostname), it returns the Tailscale FQDN I cannot find any other hostname that resolves to the 192.168.1.1 LAN IPv4 address I am expecting "ping tower" hits 127.0.0.1 "ping tower.local" returns "Name or service not known" Can I ask for some help please? npm_letsencrypt-log.txt Tower-tailscale-diag-20240517-093835.zip

I have an HP Microserver Gen10, with a customised Intel Xeon class CPU installed and oodles of RAM. It only has a single HDD behind the main disk array, which will be added to when budgets allow... It is connected via a small LAN with all media playback devices (i.e. TVs) connected to it by ethernet. While watching something via the Infuse app on Apple TV, configured to use SMB shares, the performance becomes terrible if I try to upload a new video file at the same time. This could be local system file copying or via SSH, both using different protocols to SMB being used for streaming. I cannot believe this system is incapable of performing both tasks simultaneously, and also expect equal / opposition questions about the performance of the Infuse application, which I am pursuing separately. What and/or how should I direct either the performance or to get better diagnose in future?

Having an issue deploying this templated container. I am choosing to provide a Fixed IP (192.168.1.20) and setting the ServerIP to this Unraid server (192.168.1.1). This choice allows me to leave the required default ports. Otherwise, my other configs would block this, such as Nginx Proxy Manager for routing of multiple domain traffic. When I run this container and set my laptop's DNS manually to 192.168.1.20, the Bitwarden Safari extension (pointing to the Vaultwarden container on the same Unraid) no longer functions. The Unraid UI seems to change the server-side IP address, as in the screenshot below. It starts initially with 192.168.1.20:53/TCP <--> 192.168.1.1:53 and repeated for all rows. And my only fix is to restart all networking services (reboot is simpler!) What am I doing wrong?

Noticed the Unraid system's config was to use 443 for HTTPS. I changed this to 444, and restarted. Cannot recall if this was changed or replaced.

I have a typical NPM config, from the Unraid "Apps" browser

I have had this config running since I initially built it in January

6th July 2023 Updated Unraid to 6.12.2 last week. Upon reboot, I cannot start my core container, NPM. My other core containers do start, such as a database container, password vault container, etc. I see in the system logs, NPM wants port 443, but is in use. I never had this problem before. There is an O/S-level Nginx instance running that is using 443. If it isn't created by the Unraid UI, I do not know what it is. Nor why the config changed to take this port. This would affect anyone attempting to bind this port to a Docker platform running inside the core O/S. It is an O/S-native service, by my initial view. If I try to manually start the NPM container, it prompts "Execution error" Updated Unraid to 6.12.2 this past week. Upon reboot, I cannot start my core container, NPM. My other core containers do start, such as a database container, password vault container, etc. I see in the system logs, NPM wants port 443, but is in use. I never had this problem before. There is an O/S-level Nginx instance running that is using 443. If it isn't created by the Unraid UI, I do not know what it is. Nor why the config changed to take this port. This would affect anyone attempting to bind this port to a Docker platform running inside the core O/S. It is an O/S-native service, by my initial view. If I try to manually start the NPM container, it prompts "Execution error". Forum posts from many years ago suggest editing a `/config/go` but the parameter no longer exists. tower-diagnostics-20230705-2341.zip