primeval_god

It only applies to "incremental sends". I believe its purpose is to define the "Master Snaptshot" (not a btrfs term) against which the snapshot will be compare to do an incremental send. This is a feature of the plugin vs something to do with the underlying fs. P.S. If you expand the help text (either globally or by clicking on labels like Master Snap) you will find some useful information.

Snapshots are not "based on a previous snap" they are a Copy on Write copy of a subvolume. For the purpose of restoration there are no dependencies between them, (all of the data sharing stuff is handled by the CoW nature of the FS). You can delete any of them without effecting the others . The only time the relationship of one snapshot to another really matters is when sending them between filesystems using btrfs send. With send if the snapshot to be transferred has an ancestor snapshot at both the source and destination then the amount of data to transfer is reduced (highly simplified explanation). There is not really a simple gui way to handle rolling back. Snapshots appear as just folders on the filesystem. The simplest way of restoring is to delete the live file or folder and then copy it from a snapshot directory back into place. If you are restoring entire subvolumes (the whole snapshot), there are fancier ways of doing it involving deleting the subvolume and then creating a writable snapshot of the snapshot you want to restore, but copying is the easiest to understand. Since snapshotting only involves data disks an not the OS there is no need to bring the server down when restoring something. At most you might have to stop some VM or Docker containers that are using data from the subvolume to be restored.

It is an unRAID issue since composeman does not modify the dockerman containers page. More specifically docker compose changed something about the way network naming is handled which throws a wrench in the way dockerman extracts network names for some network types. A fix is not going to be a high priority as it only effects containers created by compose and composeman is a third party plugin.

I believe the valid options for this are "bash" and "sh", shell is not.

Maybe look at doing something with docker healthcheck.

BTRFS scrubs and balances can be scheduled per disk via the gui (under the disk options i think). I dont think defragmentation is an operation that most people would want to perform regularly on BTRFS. If i remember correctly under most circumstances you dont want to defragment an entire disk as it breaks CoW deduplication. Defrag should only be performed on targeted files or parts of the filesystem if required.

At this time i have no plans to address these issues. Modifying the built in dockerman page is a bit of a pain and not something I want to muck around in right now.

It looks like you have a stack with an empty yml file. You would need to add something to it if you expect it to do anything.

What is the nature of the services you are planning to host. Personal blog, web-services for family and friends, small business site, webapp, home lab playground? What kind of uptime expectations? What kind of visibility do you expect? My recommendation in general is not to use unRAID for business (even small business, but others disagree).

My point was less about NAS vs server and more about general linux server os vs appliance os that happens to be based on linux. My opinion is that appliance devices targeted at home networks have a much lower security requirement than server software targeted at business or enterprise.

It is an unRAID concept. There is little more to it than placing all of the docker engine's internal stuff into a disk image to make it easier to manage in a system without the normal persistent install locations.

Do you mean container? Or are you actually building something form a Dockerfile? Yes there are several ways. The most robust would be to write a Dockerfile that uses the php:apache as a base image, write your changes into the file, then build and deploy it to dockerhub. Best to looks up some docker tutorials on google to get an idea of how to do that. There is also an option of committing the changes you have made to a live container and pushing those to github but that is not so easy to maintain. Either way you will be dealing with the docker engine on the command line, as there are no unRAID specific tools for this. Best advice is to read up on docker.

Technically so am I. I am referring to the various security features of linux in general, which the unRAID OS chooses not to use.

More specifically it was meant to prepare for an eventual change where the "Array" will no longer be a separate required thing. Instead what is now the "Array" will be just another type of "pool" that can be created along side the existing BTRFS, ZFS, and XFS "cache pool" types. Ideally when implemented the mover will be able to move files between any two pools, essentially allowing any pool to cache data for any other pool. It also makes it clearer that pools are not just for caching data, that they can be used for other things where data lives only on the pool.

I am doing very little with the env file actually. Pretty much the editor just creates it in the project folder, and allows you to edit it. If it works (because i am not certain i use it myself) it is picked up because it is in the same folder as the compose file. I probably should be specifying it on the command line with either the --file or --env-file command. Using the "env_file:" option in a compose service i think has a slightly different behavior. Rather than making the variables contained in the file available to use in the compose file I think it directly passes them into the container as -e options. I think this is the correct format for using the .env file as is. If i understand correctly if you used the "env_file:" option for the container then the TZ from the file would be passed directly to the container, but you may not then be able to use other variables from the .env file for substitution elsewhere in the compose file.

Consider instead that unRAID is not "a server" os but rather a "home NAS appliance os". It is more spirituality akin to the Synology OS or whatever runs on QNAP. It doesnt provide all the administrative tools of a more general linux os because the user is expected (though not required) to administer their NAS within the unRAID paradigm. It lacks many of the more sophisticated security tools because they are generally unnecessary for a home user on a home network which is unRAIDs target audience (alibi the more advanced home user). A flexible distro is, I think, exactly what unRAID is trying to avoid. Slackware's lack of simple package management is a benefit to unRAID in that it helps to enforce the "dont modify the base os" tenet. One of the benefits of dockerman is that it steers users toward the unRAID way of using docker, i.e. single container apps, bind mounts instead of volumes, simple network topology, curated apps from an appstore. Again geared toward the home user rather than the professional. For my money I would rather see limetech focus on improving the core NAS capabilities (though not ZFS, way to much time spent on that already) and commit to faster / more security patches between feature releases.

Not a bug, the compose manager plugin is an opinionated management gui. It is intended to only manage compose stacks created via its own interface, which always use the same naming scheme for the compose file and supplementary files.

Remove the version line. It is no longer recommended for compose files. Also is this a compose file you created yourself or something you pulled from a GitHub repo? If so did you specify a custom location when creating the stack? That is recommended when stacks require additional files beyond the compose file.

No idea, if I remember correctly (not able to look right now) the auto start is hooked into the unRAID started event. I am not certain if there is a specific event for docker start.

Looks like you are using a user share path instead of a disk share path. Make sure the path to your swap file is directly via the nvme disk share. Also delete both the swap file and the folder it is in before re-specifying the path. I think the help text may have a note about that.

A new version is available which adds the option to force-recreate during autostart. The option can be selected in the compose settings menu. The default behavior is not to run without the --force-recreate option.

I think it depends on how the lxc container was created. If brtfs or zfs is specified in with the '-B' option of lxc-create then it should use the appropriate backend when snapshotting.

The guide is not directly applicable to unRAID. unRAID (thankfully) does not use systemd, and changes to its system files are not persistent across reboots. You would have to write a script to make the changes required to put docker in a cgroup (whatever those are) and run it on start before docker starts.

I will look into adding an option to bring the stacks down and up on restart. The current behavior will remain the default however as stopping and starting the containers is more inline with the expected behavior for docker containers on unRAID. I dont have a timeline for when i will be able to make the changes.