Repository: static-web-server/static-web-server (language: rust)

Issue:
Issue with volume in unRAID
First off, I don't know if it's an unRAID, Docker or the static-web-server issue. I'll post this issue in unRAID forum too.

The issue is that the static-web-server uses the `VOLUME ["/public"]` and I bind some paths into the container from unRAID which fails to umount when stopping the array. In unRAID it's called path as for the `-v /somedir:/public` argument and array manages the HDD mounting and shares. The shares in unRAID are located in `/mnt/user/<sharename>`.

I've bind 2 shared folder from unRAID into a subfolder in `/public`:
 - `/mnt/user/movies` to `/public/movies`
 - `/mnt/user/series` to `/public/series`

It's working fine so far until I want to shutdown the server or stop the array.
unRAID does these following steps:
 - stop containers graceful
 - stop docker
 - umount all shares
 - stop the array

Docker stops fine but umounting all the shares fails here because static-web-server uses `VOLUME ["/public"]` which creates a new volume by docker into `/var/lib/docker/volumes/<volume>/_data` and the both binds of `/public/movies` and `/public/series` are mounted into this folder. When docker stops the binds are not linked anymore still unRAID sees the binding between them and cannot umount the shares. To do the graceful shutdown I manually umounting both of the binds directly in the `/var/lib/docker/volumes/<volume>/_data_/movies`, kill `/dev/loop2` then unRAID is able to umount all `/mnt/user` shares.
https://github.com/joseluisq/static-web-server/blob/d165213f375b5394736c97d68b348818d79b2d4a/docker/scratch/Dockerfile#L18

If static-web-server wouldn't use `VOLUME ["/public"]` thus wouldn't create a volume under `/var/lib/docker/volumes/<volume>` and the bind goes directly into the docker process so that after stopping of docker no dead mounting exists.
Issue with volume in unRAID
First off, I don't know if it's an unRAID, Docker or the static-web-server issue. I'll post this issue in unRAID forum too.

The issue is that the static-web-server uses the `VOLUME ["/public"]` and I bind some paths into the container from unRAID which fails to umount when stopping the array. In unRAID it's called path as for the `-v /somedir:/public` argument and array manages the HDD mounting and shares. The shares in unRAID are located in `/mnt/user/<sharename>`.

I've bind 2 shared folder from unRAID into a subfolder in `/public`:
 - `/mnt/user/movies` to `/public/movies`
 - `/mnt/user/series` to `/public/series`

It's working fine so far until I want to shutdown the server or stop the array.
unRAID does these following steps:
 - stop containers graceful
 - stop docker
 - umount all shares
 - stop the array

Docker stops fine but umounting all the shares fails here because static-web-server uses `VOLUME ["/public"]` which creates a new volume by docker into `/var/lib/docker/volumes/<volume>/_data` and the both binds of `/public/movies` and `/public/series` are mounted into this folder. When docker stops the binds are not linked anymore still unRAID sees the binding between them and cannot umount the shares. To do the graceful shutdown I manually umounting both of the binds directly in the `/var/lib/docker/volumes/<volume>/_data_/movies`, kill `/dev/loop2` then unRAID is able to umount all `/mnt/user` shares.
https://github.com/joseluisq/static-web-server/blob/d165213f375b5394736c97d68b348818d79b2d4a/docker/scratch/Dockerfile#L18

If static-web-server wouldn't use `VOLUME ["/public"]` thus wouldn't create a volume under `/var/lib/docker/volumes/<volume>` and the bind goes directly into the docker process so that after stopping of docker no dead mounting exists.


Discussion / hints:
Ok, I understand that the problem for your unRAID setup is because `VOLUME ["/public"]` creates an extra Docker volume that you wouldn't like to have because unRAID can not unmount it.

I believe that assuming an extra volume like `VOLUME ["/public"]` "could" be a tradeoff but the reason is because of the server defaults adopted early on by this project. In particular this one:

```sh
    -d, --root <root>
            Root directory path of static files [env: SERVER_ROOT=]  [default: ./public]
```

It defaults to `./public` which doesn't exist on a container like `static-web-server/docker/scratch/Dockerfile`.
"The logical" thing would be defaults to an already-directory in-place. But unfortunately is not the case.
However we could remove that volume instruction from the `Dockerfile` but it could break other users using the server defaults.

So it ​difficulties **at this stage of the game** to make the switch (not to do the removal which is easy).

**Workarounds/Solutions**

I'm thinking now that probably we could replace the current `VOLUME ["/public"]` with a `RUN mkdir /public` in order to avoid that Docker volume and see how it behaves. What do you think? Would that solve your problem? it would great if you can test it and let me know.

---

Clarifying also that I don't see this as an issue but more like a kind-of-feature or improvement if you want call it.

Yes, I can test it.

So in your opinion it's not a bug of static-web-server but rather a bug in docker or unRAID if it couldn't umount the paths in the volume properly?
> So in your opinion it's not a bug of static-web-server but rather a bug in docker or unRAID if it couldn't unmount the paths in the volume properly?

I don't know if call it as a `static-web-server` bug itself since the `Dockerfile` behaves as intended.
I don't also see this is an unRAID or Docker issue however as I told you we can adjust it for suite your use case better.

It's more like configuration thing that it could be made.
How about for testing purpose to push a docker image to hub with the tag `joseluisq/static-web-server:latest-novolume`? So that we can test it without bringing troubles to the users who already uses it.
> How about for testing purpose to push a docker image to hub with the tag `joseluisq/static-web-server:latest-novolume`? So that we can test it without bringing troubles to the users who already uses it.

Sure, I could publish that change so you could test it in your unRAID environment. Probably a `joseluisq/static-web-server:dev` image for that purpose.
May you share please a screenshot or log showing the extra Docker volume created and not possible to umount?
I did take it a closer look and it's possible to just remove `VOLUME ["/public"]` without issues.
It doesn't interfere with current functionality provided.

An enhancement PR should be come soon.
However  I will need your help with the testing and verification in your unRAID environment.

Ok, I understand that the problem for your unRAID setup is because `VOLUME ["/public"]` creates an extra Docker volume that you wouldn't like to have because unRAID can not unmount it.

I believe that assuming an extra volume like `VOLUME ["/public"]` "could" be a tradeoff but the reason is because of the server defaults adopted early on by this project. In particular this one:

```sh
    -d, --root <root>
            Root directory path of static files [env: SERVER_ROOT=]  [default: ./public]
```

It defaults to `./public` which doesn't exist on a container like `static-web-server/docker/scratch/Dockerfile`.
"The logical" thing would be defaults to an already-directory in-place. But unfortunately is not the case.
However we could remove that volume instruction from the `Dockerfile` but it could break other users using the server defaults.

So it ​difficulties **at this stage of the game** to make the switch (not to do the removal which is easy).

**Workarounds/Solutions**

I'm thinking now that probably we could replace the current `VOLUME ["/public"]` with a `RUN mkdir /public` in order to avoid that Docker volume and see how it behaves. What do you think? Would that solve your problem? it would great if you can test it and let me know.

---

Clarifying also that I don't see this as an issue but more like a kind-of-feature or improvement if you want call it.

Yes, I can test it.

So in your opinion it's not a bug of static-web-server but rather a bug in docker or unRAID if it couldn't umount the paths in the volume properly?
> So in your opinion it's not a bug of static-web-server but rather a bug in docker or unRAID if it couldn't unmount the paths in the volume properly?

I don't know if call it as a `static-web-server` bug itself since the `Dockerfile` behaves as intended.
I don't also see this is an unRAID or Docker issue however as I told you we can adjust it for suite your use case better.

It's more like configuration thing that it could be made.
How about for testing purpose to push a docker image to hub with the tag `joseluisq/static-web-server:latest-novolume`? So that we can test it without bringing troubles to the users who already uses it.
> How about for testing purpose to push a docker image to hub with the tag `joseluisq/static-web-server:latest-novolume`? So that we can test it without bringing troubles to the users who already uses it.

Sure, I could publish that change so you could test it in your unRAID environment. Probably a `joseluisq/static-web-server:dev` image for that purpose.
May you share please a screenshot or log showing the extra Docker volume created and not possible to umount?
I did take it a closer look and it's possible to just remove `VOLUME ["/public"]` without issues.
It doesn't interfere with current functionality provided.

An enhancement PR should be come soon.
However  I will need your help with the testing and verification in your unRAID environment.


Fix patch:
diff --git a/Makefile b/Makefile
index b0fa04f9..ce391b12 100644
--- a/Makefile
+++ b/Makefile
@@ -117,10 +117,18 @@ fmt:
 	@cargo fmt --all
 .PHONY: fmt
 
+docker.image:
+	@echo "Creating Docker Scratch image..."
+	@docker build \
+		--rm=true -f ./docker/scratch/Dockerfile \
+		--build-arg SERVER_VERSION="${PKG_TAG}" -t joseluisq/${PKG_NAME}:devel . --pull=true
+.PHONY: docker.image
+
 docker.image.alpine:
+	@echo "Creating Docker Alpine image..."
 	@docker build \
 		--rm=true -f ./docker/alpine/Dockerfile \
-		--build-arg SERVER_VERSION="alpine" -t ${PKG_NAME}:alpine . --pull=true
+		--build-arg SERVER_VERSION="${PKG_TAG}" -t joseluisq/${PKG_NAME}:devel-alpine . --pull=true
 .PHONY: docker.image.alpine
 
 
diff --git a/docker/alpine/Dockerfile b/docker/alpine/Dockerfile
index e45084ad..f8e4708e 100644
--- a/docker/alpine/Dockerfile
+++ b/docker/alpine/Dockerfile
@@ -19,7 +19,6 @@ COPY ./docker/alpine/entrypoint.sh /
 COPY ./docker/public /public
 
 EXPOSE 80
-VOLUME ["/public"]
 ENTRYPOINT ["/entrypoint.sh"]
 CMD ["static-web-server"]
 
diff --git a/docker/scratch/Dockerfile b/docker/scratch/Dockerfile
index 758e9655..2124c104 100644
--- a/docker/scratch/Dockerfile
+++ b/docker/scratch/Dockerfile
@@ -15,7 +15,6 @@ COPY --from=latest /usr/local/bin/static-web-server /
 COPY ./docker/public /public
 
 EXPOSE 80
-VOLUME ["/public"]
 ENTRYPOINT ["/static-web-server"]
 
 # Metadata


Test patch: