primeval_god

Open-Source does not imply legality. Nor is an EULA necessarily legally binding. From a quick glance at the referenced project though it looks like their "Open-Source GPU Virtualization" is mostly the upper level virtualization stuff and they still require you to use closed source virtualization drivers for the actual hardware. Edit: Just to clarify a bit an EULA is meant to be legally binding, whether or not a particular one is gets complicated quickly, and can depend on things like jurisdiction, the specific language of the document, how the user acknowledges it, etc. Enforceability is yet another matter. This post does not constitute legal advice. #notalawyer

Almost certainly. While i know nothing about this board in particular I have never known a motherboard with optional ATX power sockets.

You should not delete a running stack. Do a Compose Down first to remove containers and networks.

First you need to create the sub-directories within /mnt/disks that you want to mount volumes to. Then you will need to bind mount the directory /mnt/disks to a directory in the docker container using the shared flag "Shared". Lets say the directory in the container choose is /disks. Then in the VeraCrypt gui when you mount a volume you can click the button that says "Options" which will reveal an option to Mount at Directory. Use that to navigate to the sub-directory of /disks you want to mount to and select it.

So i finally updated my main server to 6.11.5 and having forgot about this ran straight into an issue. Have there been any changes that would allow me to prevent the webui from binding to eth1? @bonienl

Using it to copy from share to share is technically safe, but since it does nothing to prevent copying disk to share it is not inherently safe.

Unfortunately these labels are not really documented. They were added as a way to integrate containers that were not created through the unRAID template system with the webui. The net.unraid.docker.managed doesn't really do anything useful. Ideally it would be set to "dockerman" for all containers created by the unRAID webui. The composeman plugin sets it to "composeman" to indicate that the container is not managed by dockerman. net.unraid.docker.icon and net.unraid.docker.webui serve the same purpose as the icon and webui fields in a dockerman template. (Edit) Since 6.11.0 net.unraid.docker.webui serves as the primary source for the webui url, the template is secondary. For net.unraid.docker.shell any of these options /bin/bash, /bin/sh, sh, bash should work just fine assuming they match the shell available in the docker container they are being applied to. The issue you are facing is probably the fact that the labels dont update properly, which is currently a bug with unRAID. The only way i know to get the updates to apply is a server restart.

No some SMR hard drives use trim for performance optimization. https://superuser.com/questions/1407990/what-does-trim-on-an-hdd-mean

I am having an issue all of a sudden with big picture mode not loading correctly. Could it be related to this new big picture mode? Has it made its way out of beta?

Note that this appears to be a fairly old article. WD has since changed their branding such that WD Red drives are SMR and WD Red Plus and WD Red Pro are CMR.

A good tool to use for viewing compression is compsize. Unfortunately i dont know that there is an easy way to install it on unRAID. I personally had to build it locally with the slackbuild on unRAID 6.9.2.

Enabling compression in BTRFS will not automatically compress existing files. Compression will only apply to files created after the setting is applied.

BTRFS does offer snapshots if you have any need of them. I use single drive BTRFS for my cache drive and use snapshots to backup my appdata folder (not backup against drive failure but against accidental deletion of configuration breaking). It also offers the ability to do send and receive between BTRFS drives. I have not personally had any issues with corruptions on BTRFS file systems and have a mix of BTRFS and XFS drives in my array.

It is this, though its not specifically when a container is updated rather it is every time a container is recreated. The answer to why it happens is because docker does not automatically delete volumes when a container is removed, and unless you specify a named volume it wont reattach the volume a new container. There are a couple of options. The first would a creating a script to periodically cleanup unused volumes. The docker cli has a purge command (not sure of the exact syntax) that will remove unused volumes. The other option would be to ensure that they never get created in the first place. When creating a docker image the author uses the VOLUME keyword to specify which paths must be backed by a volume. When running a container specified paths must either be attached to a volume or a bind mount. If the user does not specify a named volume then docker automatically creates an anonymous one for that container which ends up being your problem. In unRAID we typically use bind mounts but template authors might not always specify a bind mount for every volume in the image (typically because it is of no use to the user or it is unknown to the author since many dot create the images that they host templates for). You could use docker inspect on your images to determine which ones have anonymous volumes attached and then add path mapping to there templates.

I can though I am not sure what help it would be. Unlike the case with docker, the paths/subvolume names to exclude for urBackup will be unique to each installation. My hope would be for a way to enter one or more arbitrary paths and the plugin filter out any subvolume/snapshot mounted at that path or in a subdirectory thereof. Similar to the exclude textbox available in the File Integrity plugin for example.

Is there a way or would it be possible to add a way to exclude custom paths from appearing in the interface? In my case i am using urBackup on one of my array disks and it produces a lot of subvolumes and snapshots which clutter the interface and are not something i have a need to manage outside of urBackup.

I see no implication that XFS support will change in any way, only a change in nomenclature. XFS will still be a filesystem option for disk in an unRAID array, an unRAID array will just be considered a type of pool. Likewise the option to have a single XFS formatted "cache drive" will still exist, only it will be referred to as a type of "pool" even though technically speaking a pool with only one drive isnt pooling anything.

I am not sure i understand what you mean by bridge. The containers are exposed through one interface and the unRAID UI through the other.

I am aware of the underlying issue. The issue appears to be that changes to the webui container label are not reflected in the webui. Unfortunately so far as i can tell this is not a bug with the compose plugin but rather with the unRAID webui itself. It may be fixed by rebooting the server but I am not in a position to test that at the moment.

Has there been any change since the last time this issue was updated?

Understood, however it does seem like the question "can i run unRAID on my QNAP/Synology/etc" comes up quite often. While not the most common there are some cases of people running unRAID on the x86 version of some off the shelf NAS devices. It seems likely that the majority of home NAS devices in the wild are off the shelf "embedded" units rather than the custom boxes we build. In fact I was seriously considering buying one of those off the shelf x86 4 bay devices to run unRAID on for a backup server a few months ago. I was having a terrible time finding any small 4bay itx cases for a custom build and those units were looking like my best option. I did end up finding what i needed for a custom itx build however.

This is actually incorrect. Many of the lower to mid range off the shelf NAS solutions do in fact have ARM chips. QNAP, Synology, Western Digital, TerraMaster all offer both ARM and x86/x64 based NAS devices depending on price-point. Which is not to say that many people are running unRAID on off the shelf NAS boxes. Just that ARM based NAS hardware is not unheard of.

As far as any of us in the forums know the answer is no. Limetech tends to be fairly tight-lipped about their roadmap and which features they are considering. That said arm support in linux distros is far from ubiquitous at this point and tends to introduce a myriad of platform specific issues. It seems like it might be a quite a challenge for a team as small as Limetech to implement and support. Unfortunately, due to their size, getting the attention of a Limetech employee on this forum can sometimes be difficult. Much of the time well meaning members of the community step in to answer questions, with varying amounts of tact. UnRAID is first and foremost a Home NAS Appliance OS. While it does have a lot of capabilities beyond that of many home NAS solutions (thought VM and Docker support are quickly becoming par for the course for most NAS solutions), it is simply not designed to be a fully generic linux server distro. So many people come to the forums asking "why cant unRAID do X that another server distro can do" that sometimes our first instinct is to ask what they are trying to accomplish to determine if unRAID is even the right tool for the job.

Looks like the issue with zigbee2mqtt and netdata is possibly this