primeval_god

Defragmenting is not recommended for BTRFS volumes under normal circumstances, especially not if snapshots are being used. Defragmenting breaks CoW sharing between files, snapshots etc. It certainly should not be done filesystem wide.

It mostly depends on what you want to do. The compose manager plugin is focused on supporting simple compose stacks from the unRAID webui. If you are looking to create complex compose stacks or utilize off the shelf compose stack provided by projects not designed explicitly for unRAID you might be better served with a more full featured container management solution like portainer. Either way keep in mind that compose is not native to unRAID. Integration with the webui will be incomplete.

systemctl is part of Systemd they are not different things. There is no simple way to update components like the docker engine separate from an OS release in unRAID. Regardless it is unlikely to be an issue with the version of the Docker Engine. It is more likely to be an error in how your configuring the container. Unfortunately i know nothing about onlyoffice so i cant really help there.

Currently unRAID requires there to be at least one drive in the "Array" (meaning the disk pool that uses the unRAID driver), regardless of what other pools are specified. For people who want to use only ZFS pools and no unRAID "Array" the workaround is to assign a single small USB flash drive (other than the boot drive) to the array to satisfy the requirement. Unfortunately the drive does still count against drive limit for the particular unRAID license level. It is expected that this requirement will be going away at some point as Limetech makes further improvements for supporting drive pools. Unfortunately, as is the case with most unRAID development, there is no ETA for that feature.

Luks i think.

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.