primeval_god

Depends on who you ask, but it has been quite a while since that was the general consensus.

The main reason I asked is because, generally speaking, BTRFS and ZFS offer a lot of the same advantages. Both allow multi-disk pools, both have data integrity features, both have snapshots, both offer a delta based method of sending snapshots from one fs to another. ZFS pools can apparently offer faster speeds at the expense of more resources. ZFS pools are less flexible in their layout and in terms of expanding them, BTRFS is more flexible (though not as much as the unRAID array) but lacks a stable raid5 or raid6 option. In the wider linux community ZFS is considered more stable than BTRFS (opinions vary on the stability of BTRFS), but in unRAID BTRFS has been integrated for longer.

Is this only about ZFS vs XFS (BTRFS excluded)? If thats the case then one of the answers is to the above is multi-drive pools vs single drive pools.

No the "Compose Up" button in the webui executes 'docker compose up'. Images are pulled as part of the up command not with a separate command.

The compose manager plugin is really designed with simple stacks in mind, it was not my intention to support all possible compose cli settings. Does settings COMPOSE_PARALLEL_LIMIT in the .env file have any effect?

This might help,

I dont know what the above section does but it it seems to break things. The following works just fine with a version: "3.9" services: tautulli: image: lscr.io/linuxserver/tautulli:latest container_name: tautulli environment: - PUID=1000 - PGID=1000 - TZ=${TZ} ports: - 8181:8181 restart: unless-stopped networks: br0: ipv4_address: 192.168.1.133 volumes: - ${DOCKERDIR}/tautulli/config:/config with an env file like this TZ=UTC DOCKERDIR=/mnt/cache/appdata placed in /tmp/env-test-2/

Can you give me a simple composefile and env file combination illustrating the problem?

The cli equivalent is docker compose up, not docker pull. The images are pulled as part of the up process.

Are you certain? Have you tried it? If I understand correctly specifying the env file using the --env-file flag in the compose command (which is how this latest change works) is the equivalent to having the env file in the same folder as the compose file rather than being the equivalent of specifying the env file in the compose file using the env_file section.

Ok in that case you have as much information as is available about the compose up process. It is the direct output of the compose utility, no different than if you were to execute compose up via the terminal.

What output style are you using? Check the compose manager setting page.

I am sorry @L0rdRaiden but at this time I have no plans to add docker scout to the compose manager. I would prefer to keep the contents of this plugin as tightly focused on supporting simple compose stacks as possible. Additionally I already get some flak for not keeping up with the docker compose releases I am not really keen on adding something else i wont keep up to date. The bits of this plugin that actually pull and package the compose binary are fairly simple if you were interesting in making a plugin for installing docker scout though.

Actually I made some changes beyond yours, the UI integration is done and i changed the name of the envToUse file. There is now a button for each stack called "Settings", selecting that will bring up a popup window with a field where you can change the path to the env file for the stack. There should be no need to manually edit files in the projects folders. @mrpops2ko With this new functionality you can specify a shared env file for some or all of your stacks.

The term Array is a holdover from when unRAID used to be a one pool system, eventually the term will be replaced. The "Array" is the required (currently) disk pool using the proprietary unRAID pooling driver. The unRAID pool provides single or double redundancy, mix and match file systems, easy expansion, and most importantly disks with filesystems that can be mounted independently of the others for disaster recovery. Its the unRAID in unRAID. Currently every system must have one and only one "Array" present for the system to function.

With docker you can bind mount as many folders as you like into the container, the options in the template are just the suggested setup. Once mounted they are available to add to plex libraries as any other folder would be within the docker containers file system.

My extremely biased opinion is that, within the unRAID array, zfs provides no benefits over BTRFS. The only time I would suggest using zfs on an array disk is if you are making use of zfs cache pools and want to be able to easily send snapshots between the pool and arrays.

See my previous answers. I expect the old update process will be replaced with the new one in a future OS update. However since its built in it cant be changed short of a full os update. Thus in order to make the new updater available to people immediately limetech has added it to the connect plugin.

Not sure what you mean. If the question is why distribute it via the connect plugin, the answer is likely that its the best way to get it on existing systems before people upgrade to the latest version of unraid. The existing update tool is part of of webui not a separate component. So far as I know, it cant be updated short of a full os upgrade.

unRAID currently requires at least 1 drive to be configured in the unRAID Array. It can even be a flash drive however it does count against the total drive limit.

I think they mean that the new updater tool will be integrated into the unRAID OS in a future release (replacing the existing update "Update OS" tool/workflow). If you want the tool now, it is included with the connect plugin which is a separate install.

The best way would be to create a new project with the gui, then copy the files from your old project into the new project directory. The stack must be down for this to work. The compose manager plugin is really designed for managing simple compose stacks created through its webui (similar to how dockerman is designed to manage containers launched via dockerman). Compose stacks launched via other means, including the command line are not explicitly supported. Additionally compose projects pulled from github (or other such places) are not explicitly supported as they, like random dockerhub images, are not necessarily designed with unRAID in mind. All that to say if you are beyond a simple single compose file and an env file, here be dragons.

Not to my knowledge. Is traefik configured to log to a file or to stdout?

Has anything changed on your system recently? Any changes with your stacks? Anything in your system log?

When creating a stack there is an advanced option (in a dropdown at the bottom) for specifying the project location. If you need to add extra files to the compose project (such as a build directory) you should select a project location on a pool or array.