Don't use this on a QNAP NAS

[Sascha8]

After install you can't remove app and containers from container station anymore. Only a de- and reinstall of container-station helped to get rid of this. Tried on cmd line with docker app uninstall - QNAP docker don't support the param "app".

[merlinschumacher]

Could you tell me which "app" parameter you refer to?

We never tested this system on NAS devices due to their varying software layout. A Raspberry Pi or an X86 server is recommended.

[Leinetaler]

For QNAP NAS using "Container-Station" you can install each docker container from this collection seperatly.
The docker compose installation script will not work.

[Sascha8]

Could you tell me which "app" parameter you refer to?

Sorry, not really... I don't remember anymore... I am still sure that on QNAP the "docker" cmd don't support all parameters.

[tiflor]

On my QNAP(AMD64 CPU) this is running quite fine, but there are some point which need reconsidering while using this project.

Containerstation from QNAP is a very lightweight frontend for docker/docker-compose and does not implement all docker or compose functionalities.
Container Station says APP to a complete compose file, same is done by the docker-compose, compare this sample app: https://docs.docker.com/compose/samples-for-compose/

To make this more convenient to work with I connect to the docker daemon on QNAP via remote connection with DOCKER_HOST set on my laptop. There is an explanation how to do it in the container station: preferences->docker-certificates. With this setup the QNAP can be seen like any other remote docker host, with all the pros and cons of this kind of setup. Sadly QNAP is providing an old version of dockerd in my case 19.03.13 while my client is already 20.10.0.

In this kind of setup I usually switch to volume mounts which contain the bind mount, this locks like this:

volumes:
  [service_mount]:
    driver_opts:
      type: none
      device: /share/[qnap-volume]/[project]/[service_mount]
      o: bind
 [service_mount]:
    driver_opts:
      type: none
      device: /share/[qnap-volume]/[project]/[service_mount]
      o: bind

With this setup the start.sh file will obviously not work, an option to overcome this is generate the files locally and copy them over to the NAS, what might need fixing in this case are the file permission, which can be handled by accessing the QNAP via ssh and set them correctly.
An alternative could be mounting the folder via smb or nfs.

For me this makes a setup with a remote docker host which runs my workloads, where I can reuse the docker tools from other setups. Container station in my case is just used to see if everything is working fine.

I would recommend to use this project on a QNAP because you benefit from all the work done in this project which gives smooth start, but you should be willing to invest some time to learn the specialities of your device.