The reason likely that it doesn’t allow exec even in the docker volume to my surprise.
You may see an error during the run of the container, if you would temporary replace -d option with -it, it should print everything to the console.
Could you please show an output of the command:
docker run -it --rm -v storagenode-binaries:/app/config/bin ubuntu ls -l /app/config/bin/
Another workaround would be to use a BINARY_DIR to provide a different path inside the container.
Please try to add -e BINARY_DIR=/app/bin, this will disable the feature to persist binaries between restarts.
If you started it with -e BINARY_DIR=/app/bin, then the binary would be inside the container, they will not be exposed to the host. So, yes, it would continue to be empty.
If you started it with -e BINARY_DIR=/app/config/bin, then you need to check logs, to see where binaries are downloaded, or check it inside the container:
docker exec -it storagenode bash
then
ls -l /app
ls -l /app/config
ls -l /app/config/bin
The weird thing that it didn’t download binaries there. Even to the docker volume. And a most weird thing, that it didn’t start the node and doesn’t report anything. Is it just exiting? Or doing something?
Yes, since it cannot download binaries to the /app/config/bin location.
This is weird, that it also cannot download them to the /app/bin, but perhaps it could be related to inability to create this folder due to a lack of permissions regardless of running under root (QNAP has messed the whole docker functionality in this case).
Please try to use -e BINARY_DIR=/tmp.
But this must work, this path inside the container and it’s exist (so no need to create), the Linux wouldn’t work normally without that path. What they broke?
Please try to add an exec permission to the mount options in the /etc/fstab for that drive directly (/dev/mapper/cachedev1), then try to check:
sudo mount -a
if no errors would be thrown, then try to remount this drive (if possible):
sudo mount -o remount /dev/mapper/cachedev1
Make sure that it now has the exec permission in /etc/mtab.
I tested that on Ubuntu 20.04, the rw permission also has a exec seems, so everything is working as expected, and I do not see a noexec in your mount options in
but it’s worth to try anyway.
I do not see any reason why it doesn’t produce any single log line when you use a new image. And especially, when binaries must be downloaded to /app/bin, as specified with a BINARY_DIR variable.
Please try with the new image again, without the BINARY_DIR variable and without the docker volume, replace -d with -it and add an option --log.output=stderr after the image name. It must say something, what’s wrong with the container.
I still cannot understand, why the docker run with -it and without -d doesn’t print anything to the console. It must at least print that’s tried to start the container.
Could you please try after run the container to execute this command:
docker debug storagenode
You should get a shell in the failing container and may try to see, what is it see in the /app/, /app/config, /app/config/bin.
