Acris / docker-shadowsocks-libev

Build a docker image for shadowsocks-libev with v2ray-plugin, based on Alpine Linux.
https://hub.docker.com/r/acrisliu/shadowsocks-libev/
MIT License
303 stars 95 forks source link

Docker compose mount volume is empty #38

Closed KHN190 closed 1 year ago

KHN190 commented 1 year ago

I have the config file as:

version: "3.7"
services:
  shadowsocks-libev:
    container_name: shadowsocks-libev
    image: acrisliu/shadowsocks-libev:latest
    user: root
    #...
    volumes:
      - /etc/letsencrypt/live/mysite:/root/certs:ro # !!
    #...
      - ARGS=--plugin v2ray-plugin --plugin-opts server;tls;host=mysite;path=/v2ray;cert=/root/certs/fullchain.pem;key=/root/certs/privkey.pem -u

The container has nothing in /root/certs. Run docker directly from command line also mounts an empty directory:

docker run \
-e "ARGS=--plugin v2ray-plugin --plugin-opts server;tls;host=mysite;path=/v2ray;cert=/root/certs/fullchain.pem;key=/root/certs/privkey.pem -u" \
-e PASSWORD=verysecurepassword \
-v /etc/letsencrypt/live/mysite:/root/certs \ # ??
--user root \
--name=shadowsocks-libev \
-p 8388:8388/tcp \
-p 8388:8388/udp \
acrisliu/shadowsocks-libev

But after the container's built, I can create a debug image locally and mount the volume with:

docker ps -a # read the container hash
docker commit container_hash debug/ss
docker run -it --rm --entrypoint sh -v /etc/letsencrypt/live/mysite:/mysite debug/ss

And see the cert in /mysite. How do I make it work for docker-compose.yml? I don't see any difference.

Acris commented 1 year ago

Hi, please try running ls -al in the container with the following command and paste the output here:

docker ps -a # read the container hash
docker exec -it container_hash ls -al /root
docker exec -it container_hash ls -al /root/certs
KHN190 commented 1 year ago

@Acris because the container cannot be started (thus no direct exec -it) so this was from a clone:

# ls -al /root
total 16
drwx------    1 root     root          4096 Sep 20 18:46 .
drwxr-xr-x    1 root     root          4096 Sep 20 18:46 ..
-rw-------    1 root     root            16 Sep 20 18:47 .ash_history
drwxr-xr-x    2 root     root          4096 Sep 20 13:21 certs

# ls -al /root/certs
total 8
drwxr-xr-x    2 root     root          4096 Sep 20 13:21 .
drwx------    1 root     root          4096 Sep 20 18:46 ..
Acris commented 1 year ago

What are the cert file mask permissions on your host? please take care to remove any sensitive information that may appear.

ls -al /etc/letsencrypt/live/mysite
KHN190 commented 1 year ago

@Acris They are all root owned by the host. As they are auto managed by certbot. Like:

# sudo ls -al /etc/letsencrypt/live/mysite
total 8
drwxr-xr-x 2 root root 4096 Sep 20 12:27 .
drwx------ 3 root root 4096 Sep 20 12:24 ..
lrwxrwxrwx 1 root root   33 Sep 20 12:26 cert.pem -> ../../archive/mysite/cert3.pem
lrwxrwxrwx 1 root root   34 Sep 20 12:26 chain.pem -> ../../archive/mysite/chain3.pem
lrwxrwxrwx 1 root root   38 Sep 20 12:27 fullchain.pem -> ../../archive/mysite/fullchain3.pem
lrwxrwxrwx 1 root root   36 Sep 20 12:27 privkey.pem -> ../../archive/mysite/privkey3.pem
KHN190 commented 1 year ago

Oh, I think I found the problem. My symlinks are fine, but the original certs are somehow not set to correct permission.

-rw------- 1 root root 1704 Jul 27 08:40 privkey3.pem

I think just change it to 777 by root should fix that. And it's irrelevant to this repo. Thanks for help.

Acris commented 1 year ago

You're welcome, glad to hear you've solved the problem, I was just running a test of a docker container mounting a soft link. :)

KHN190 commented 1 year ago

Just in case other people run into the same issue and to articulate this:

Docker treats symlinks inside the container, so when I do ../../archive/*.pem it looks for the relative path in the container while it only exists in the host. So the solution is to mount the whole /etc/letsencrypt to make the symlink works.

Alternatively, you can manually make a copy instead of using symlinks, but certbot doesn't automate that. I also thought it was the permission but not really.

This is known here and discussed in letsencrypt forum too: https://stackoverflow.com/questions/47791396/letsencrypt-docker-the-best-way-to-handle-symlink


It's confusing that manually run docker run -it .. treats symlinks on host, instead of looking for them in the container. The behaviours are inconsistent.

I'm closing the issue.