strike

To answer your question first, there's really no "easy" way to do this, but here are a few commands that can be useful. If you want to never think about port mapping again, scroll down to my last option. This command will list all containers and their exposed ports: docker container ls --format "table {{.ID}}\t{{.Names}}\t{{.Ports}}" -a And to find an available port, the easiest way is to run the same command and just grep for the port to see if it's in use or not. Say you want to install a container that use port 8080 by default, then you run this: docker container ls --format "table {{.ID}}\t{{.Names}}\t{{.Ports}}" -a | grep 8080If it returns an empty result, the port is available, but if it returns a container name and port, you know it's in use. So you run the same command again and just put a random port like 5035 to check if it's available, and if it is, you use that in your port mapping. OR ( the "right" and more secure way to do it) You can change all your containers' network to a custom network like br0 and assign each container its own IP. Then the port mapping is irrelevant, as the containers expose all ports, and since it's using a dedicated IP, there will be no port conflicts. The best way is to use a macvlan network for this; you can change this in Settings -> Docker (you might have to toggle the advanced view button. After you have done this, you have to set the network type for each container to custom br0 or create your own custom network. Then, under "Fixed IP" set an IP that is outside your router's DHCP range. Then you're done. One thing you should know tho, is that by default containers on a custom network can NOT talk to containers that use the host or bridge network (unless you enable host access to the custom network in Settings-Docker). This is for security reasons, and you should only enable it if you need to. The only thing you need to worry about when deploying your containers now is to set an available IP instead of port, which is far easier IMHO. And if you sort all your containers by IP (like I do), it takes 1 second to see what the next IP you should use is. No more worrying about ports; you simply use the default port set by the container.

Well, the only pros for using a folder I can think of are that it dynamically expands, whereas with a vDisk you have to delete the image and recreate it with a bigger size if it ever gets close to full. The con tho is that if you one day need to copy/move the docker folder elsewhere for whatever reason, it's gonna take forever. This is because it consists of millions of small files. And with a vDisk is just one big file. And we all know that it's quicker to copy/move one big file vs millions of small files. With a vDisk tho, you would just delete and recreate, as copy/moving the image can cause corruption. I personally prefer using a vDisk. I think it's super easy to just nuke the image and recreate it if I need to. It takes like 5 min to install all the containers again. I tried using a folder once, but I had issues with it. Can't remember what it was tho, but I switched back to using a vDisk.

It's because you're using docker folder instead of a vDisk. If you want to change to a vDisk image, you need to change that in Settings> Docker

Yeah, I wouldn't worry about it. With docker containers and maybe VMs, your cache drive will be almost constantly writing. I went down this rabbit hole myself in the early days of using unraid and learned that this is just something I have to live with. You would think that it wears down the drives faster, and it does to some degree, but not enough to worry about. It's just very small writes most of the time. You can look at your drives' health by clicking on it and checking the attributes tab. In the end, It's all the linux ISO downloads that are gonna wear it down faster than the small writes do.. :P

The size of the snapshots depends on how much data changes over time and can very well grow to the same size as the vdisk itself. The more I look at it, it definitely looks like the "no space error" is the culprit. Could you stop the VM and run this on the terminal: qemu-img check -f qcow2 "/mnt/nvme/VMs/Windows 11/vdisk1.31-05-2026--generateqcow2" (replace with your path to the vdisk) Here is some info I just googled about snapshots Initial Size: At creation, a snapshot only requires about a few megabytes of metadata overhead. Write Activity: As the VM runs and new data is written or modified, the snapshot records these "deltas" (changes). If you change 5GB of data, your snapshot grows by 5GB. State vs. Disk: If you take an external or internal snapshot of just the disk, space only scales with disk writes. If you also snapshot the active VM memory (RAM), it will add the exact size of your assigned RAM to the snapshot size. Growth Limits: The maximum theoretical size of a snapshot is the total size of your virtual hard disk, plus the size of the VM's RAM. Internal Snapshots: All state data and disk changes are bundled and saved directly inside the original .qcow2 disk image file. External Snapshots: Changes are saved to a new overlay file (called a backing chain), while the original .qcow2 file remains untouched. These overlay files are typically stored in the default image directory: /var/lib/libvirt/images/ Temporary Snapshots: If you pass the -snapshot flag directly to QEMU, changes are stored in temporary files usually placed in /tmp/ or /var/tmp/ until the VM shuts down. You should also check out these links for more on snapshots and how to manage them on unraid: https://docs.unraid.net/unraid-os/using-unraid-to/create-virtual-machines/vm-setup/#vm-snapshots https://forums.unraid.net/topic/191371-is-there-any-documentation-or-tutorial-on-unraid-7-snapshots/ Edit: It could also be wise to check where your libvirt.img file is stored (in the system share by default) and check that the space is sufficient on that drive.

When you say you did a "hard shut down", do you mean you force stopped the VM or did you do a hard shut down of the server? According to the libvirt log there's a IO error: 26-06-11 21:10:12.964+0000: 30553: warning : qemuProcessHandleIOError:976 : Transitioned guest Windows 10 (work) to paused state due to IO error Have you made any changes to the VM template lately? Removed devices or attached new devices? Do you have a backup of the libvrt.img? Maybe you can try to restore it if you have one. Edit: One more clue(?) in the quemu log: 2026-06-11 21:10:12.964+0000: IO error device='virtio-disk2' node-name='libvirt-3-format' reason='No space left on device' Looks like one of the disks attached to the VM is full. Try removing all disks except the windows.vdisk and see if it starts.

Diagnostics can maybe help, but you should let the OP have this thread for himself and post your own thread and attach the diagnostics .zip. It could be messy if 3 different users post in the same thread. Even if you all have the same issue it could be for different reasons and have different solutions.

First, check that you guys have updated the Connect plugin to the latest version, then open a terminal and try this: unraid-api stop unraid-api restart Then try to sign in again.

This is completely normal. These apps are very active for a number of reasons. Background Databases: The apps constantly update their internal databases to record state changes, inner task progress, command statuses, and scheduled tasks. Background tasks run as often as every 90 seconds, causing persistent, low-level write activity. Active Refresh & Monitoring: They operate with a hard-coded task (often every 1–15 minutes) to "Refresh Monitored Downloads" and regularly synchronize RSS feeds with your indexers. Frequent Metadata & Log Updates: They routinely fetch or refresh artwork, cast data, and episode metadata. Additionally, they persistently write operational text logs to disk depending on your configured log levels. Any app with a database, you can usually expect a lot of disk activity.

Which firewall do you have? I use pfsense, and when I first set up tailscale I was messing with SMB. Can't remember whether it was because of speed issues or because I couldn't get it to work at all. Long story short, I opened port 41641 on pfSense, and BAM, everything worked like a charm.

Sure, but you have to set the WEBUI_PORT variable, and I think I had to add the same port as a new port to get it to work. Been a while since I did it, but I see I still have it there in the template.

Change to a custom network like br0, then the IP field appears again. Be sure to set an IP outside your router's DHCP range so it doesn't create a conflict later on.

Maybe the parity 2 drive is a SAS drive? If it is, then install the SAS spindown plugin.

Set up syslogserver in the settings and mirror it to the USB stick, then you'll find it there.

No, I'm not saying that. I'm not using Pi-Hole myself right now, so I haven't tested it, but you're probably right in what you're saying. If you did the research, I'm taking your word for it :) It makes sense. But I still recommend installing it on a pi or something, especially if what you're saying is correct. My server is also on 24/7, but I do take it down for updates and maintenance pretty regularly (at least every 2-3 months). And sometimes when you least expect it, it stays down for a while for whatever reason. Usually, there's only one official template for a container image. But almost all templates are made by unraid community members. There are also a few app developers who use Unraid and create the templates themselves, but most official templates are created by Unraid members who have no affiliation with the author of the app. This is just to make them easily available in the app store. So there can be many templates for a container, but usually only one official. Like @tjb_altf4 said, Official just means that it's using the official image the author of the app made. Usually, you'll find a support thread for a container on Unraid, but some template authors just link to the official support channel for the app. But in your case, you should post in the binhex thread already mentioned if it's an issue with outdated variables, as you said.

Before you go and install pi-hole on unraid you should know there's a caveat to running this on unraid; Every time your server goes down(reboot, stopping the array, updating the container etc), your DNS will go down, meaning you're unable to reach the internet on any of your devices. The ideal setup: Many Unraid users run Pi-hole on an always-on dedicated device (like a Raspberry Pi or a mini PC). If you do decide to install it on your server, you should set your secondary DNS on your router to Cloudflare's DNS (1.1.1.1) or Google's DNS (8.8.8.8). That way, when your server goes down, your devices can still reach the internet using the secondary DNS server.

Valid question. It's kinda confusing if we have to downgrade to get the latest security fixes. First time I'm seeing this approach.

Apprise is a notification app, you'll find it in CA :)

If you have already added the movie to Radarr, yes. But if not, it doesn't work (IIRC)

Unless the movie is already added in radarr (waiting to be grabbed), you can't get radarr to post-process it automatically. But if it already exists, it should work fine. Been a while since I've done it, but I did add some movies manually in my download client some years ago, and just added the category there; Radarr picked it up fine. But if it doesn't already exist in radarr you have to add it manually or write a script to add it. I see movarr has the option to define a apprise url, so you can be notified, but @binhex needs to add support for it to notify for new movies. We can just change the category in the .yml file if we want to, right? I think I saw it defined there.

You don't say what network your container is using, but you can't change the container port; you must use bridge mode and change the host port. If you're using a custom network with its own IP, then ports don't matter as all ports are exposed, so you just use the container port.

With this comment you posted earlier, I was sure it was, yeah. But if it wasn't, then I apologize if you took my comment personally. I just can't stand these comments in most stable release threads, and I couldn't bite my tongue. What I've learned as an IT hobbyist over the years is that you should always consider software as beta. Stable is just a beta with bugs that no one has found yet. You may not get the opportunity to encounter them yourself, but trust me, if you look hard enough, they're there. Probably just a one-off, yeah. But if you want to dig deeper, you should post your own thread if you have the diagnostics from when it happened. If you don't, then it's anyone's guess.

I'm not a Plex user, but I know many of you use it, and I wanted to give you a heads up as I stumbled upon this: https://www.plex.tv/blog/new-lifetime-plex-pass-pricing/

Nothing went wrong. This is how software development works. There will always be small groups that have issues no one else has. There will always be small bugs, even in stable releases. The devs are not gods and do not possess or have the power to test releases on every hardware configuration out there. That is wise, but even then, you're not 100% safe. Life is not 100% safe, shit happens, always.. It's just a question of when.

See Q29: documentation/docker/faq/vpn.md at master · binhex/documentation · GitHub