primeval_god

It all depends on the image. Images can be hosted on any number of docker registries of which Docker Hub is the default and most common. The way to tell for a particular image is to look at the image name. The image name format is typically <registry-url>/<namespace>/<image>:<tag> i.e lscr.io/linuxserver/plex:latest. If the image name omits the <registry-url> i.e. linuxserver/plex:latest then the default registry is docker hub. Some other widely used container registries are ghcr.io (Github Container Registry) and quay.io. The linuxserver.io images are special they use lscr.io which is not itself a container registry but rather a redirection services that forwards you to whichever of the big container registries they are currently using. Last i was aware they were by default using ghcr.io, though they also keep images up to date in several registries and may do some sort of failover if on is down.

The original issue that this user posted has been split into 2. This particular one is about resumability for the download of unraid OS updates. The other issue is about docker updates.

This statement is a bit confusing. Assuming we are are still talking about pulling docker images, they dont come from github. Docker images come from a container registry, typically hub.docker.com sometimes ghcr.io (which is technically provided by github the company but is not the same as pulling from a github repo).

Unraid updates are a different story. That is fully within Limetech's ability to handle. You should probably make it clear in the request that you are talking about two distinct issues. Resumable docker image pulls and resumable unraid update downloads.

Unfortunately this isnt really an unRAID thing this is a function of the Docker Engine. When you update or install a docker container, either with unRAID or any other docker frontend, the docker pull command is running to pull the latest image into the docker store. Images are pulled layer by layer and if an interruption occurs any partially downloaded layers are lost. Any fully downloaded layers should remain on your system and you should only have to download the incomplete layers, however some docker containers have large layers which i assume you are talking about.

Just to follow up I have identified the change that caused this and have made a bug report. https://forums.unraid.net/bug-reports/stable-releases/723-docker-page-does-not-respect-the-page-view-display-setting-r4295/

Despite the fact that I am definitely not AI, I do sometimes have a frustratingly short context window...

The tabs are an alternative to linear sections on the page. In the tabbed view sections were shown as tabs side by side instead of sections one after the other. An artifact of this was that a single section was displayed as a single tab. All of that is beside the point though. What I am noting is that tabs no longer appear on the docker page only (as far as I can tell), even when the compose plugin is installed which adds a second section. Something has changed in the layout that I don't really understand (despite the plugins I maintain, web ui stuff is not my forte). Any guidance from limetech or other plugin devs would be greatly appreciated. As an aside the tabbed, Azure theme is by far my preferred layout.

Yes the tabs are there when the compose plugin is installed (of which i am the maintainer). The layout however has never changed across updates before, and doesnt seem to have effected any other tabbed page on the system. Its also as far as i am aware not specific to the theme but a function of the "Page view" settings (Tabbed vs Non-tabbed).

I just updated from 7.1.2 to 7.2.3 and for some reason the Docker page no longer appears tabbed. Other pages dont seem to have changed.

I use urBackup for all my systems. It supports both windows and linux, both image and file based backups, and both local network and remote backups. One nice thing is that it is centrally managed meaning you can configure the settings for all the clients and trigger backups from the server interface. It supports deduplicated backups on a number of different storage types. It offers synthetic full backup types, where any backup can be deleted without effecting the others. There is a docker container for both the server and client.

I wouldn't say misnamed just not super descriptive. I believe the white theme is more or less the base color and layout of the webui. The black theme is essentially the dark counterpart to the white layout. Azure is both a color and layout change and I believe the is a dark mode equivalent theme for that layout as well. There was a plugin but last I dont think it is supported by the lasted version of unraid https://forums.unraid.net/topic/87126-plugin-theme-engine-a-webgui-styler/page/10/#comment-1593877

I mean that is the point of posting in "Feature Requests", but i think it unlikely that there would be that much demand for it. Mostly because people will see it as added complexity for little benefit. As stated above the biggest benefit I see to adding distrobox to unRAID is to try and corral users into using the recommended environment/workflow on unRAID. No need to keep telling people to "do it in a container" if they are already in a container. Possibly, a basic plugin could be fairly simple to develop and there are a good number of talented and friendly developers here. That said its a bit of a hard sell as you are more or less asking them to do all the dev work and offering to help with testing.

It would be totally possible to have a distrobox plugin for unRAID, I know because i played around with it for a while back at v6.12.15. In terms of getting a distrobox package installed I was able to build a distrobox package for unraid using the slackbuild without any customization. Getting distrobox running was also simple though it required running mount --make-rshared / as described here. I used it for a while on unraid with only a few stability issues that I never pinned down to being related to distrobox (plenty of other customization on my system). I stopped using it because there wasnt really much i needed it for at the time. I do continue to make heavy use of distrobox on my desktop, where it forms the basis of my day to day environment. So far as the feature request goes I really think that Limetech should consider integrating distrobox into the unRAID experience. I think it could solve what i consider to be an issue with the current unRAID ecosystem. Namely the number of newcomers and power users constantly looking for a way to install some package that they want to use from the command line. The answer since v6 was introduced has always been dont install things directly on unRAID, use a Docker or an LXC container or VM, to isolate them. I understand that the barrier for entry for those solutions can be high if the app they want isnt in the app store; and thats where distrobox could really help. With the right integrations the default command line environment for users could be containerized and running whatever distro the user is most comfortable with. People could install the CLI tools they want inside the containerized environment without affecting the unRAID host and the minimal isolation distrobox provides would allow them easy access to the system and their files without needing read to much into docker bind mounting.

Though i knew him only through his contributions to unRAID, his dedicated work has improved my life. He has left an indelible mark on this OS and these forums. He will be missed. RIP.

If you enable the debug option on the compose manager settings page, then you should be able to see in the system log the exact compose command the plugin is using.

If you havent already this should be reported as an unraid issue in the Bug Reports subforum.

I dont suspect that ARM support is anywhere on the roadmap, but even if it were running unRAID on and ARM based MAC is unlikely. So far as i know the one project trying to bring linux to apple silicon is only up to M2 chips and progress is slow.

I am not entirely sure what you were trying to do here. The correct way to "migrating" container would be to remove them using the webui, and then create new ones with compose. You shouldnt have to muck with any of dockermans files as the dockerman should handle all that. In the settings page for the compose plugin there should be an option to enable debug logging. If you turn that on and reboot does your system log contain any lines indicating that the compose plugin is trying and failing to autostart?

Do you want an ephemeral container (i.e. one that only exists while you are in it) or a long lived one that you can come back to? For something ephemeral you should be able to do something like docker run --rm --it <other options> ubuntu:latest bash which i believe should start and drop you into the container, you can leave the container shell and exec back into it later but when you stop the container, or if you exit the initial shell it will be remoevd. For something longer lived you should do something like docker run -d <various options> -l net.unraid.docker.webui="bash" ubuntu:latest sleep infinity it should start a container which you can exec into or use the webui to open a console into. Note this is just of the top of my head, I havent had a chance to try these out yet.

It will not, so far as i know it is not possible to fix the issue short of recreating the containers. Yes it is wrong. The reason for the third party status is mentioned much earlier in this thread. Recent versions of Dockerman use a container label "net.unraid.docker.managed=dockerman" to determine which containers it created/manage. The absence of this label indicates a third party container, and containers that were created in older versions of unRAID dont have the label. So far as i know there is no way to add or change the label of a container once it is created, the only option is to recreate it. Recreating a container generally should not be a big deal, docker containers are meant to be ephemeral not long lived fixtures like VMs. Recreating a container does not necessarily entail an update or a version change. If your goal is running specific version of a container, relying on never recreating the container is not a particularly good method. You should be using a tagged version of the image that does not change for instance "linuxserver/ffmpeg:7.1.1" instead of "linuxserver/ffmpeg:latest". If the image you are using does not provide specific tagged versions you can create your own by using the docker cli to create your own tag of the image version you are currently using. Ideally you should be able to pull officially tagged versions from docker hub at any time, but for safety and if you create your own tags you should take care to ensure you dont delete the specific image from your system. Thing to avoid are the checkbox when removing containers that asks if you want to also remove the image, and commands or plugins that cleanup unused images. Additionally for your own tagged images creating a second tag for archival can save you if you accidentally choose the remove image option when deleting a container. Note: there are a small number of containers, specifically from linuxserver.io that do update the application within the container whenever it is restarted. Tagging will not help with these, but neither will never recreating a container.

No sorry, I use an LXC container to host my pihole with Keepalived.