Docker-compose nginx with letsencrypt -> ln: failed to create symbolic link - Not supported

Question

Setup: Docker on OpenSuse-Server on local Intel-NUC

Here is my docker.compose.yml

version: '3.5'

services:
  proxy:
    image: jwilder/nginx-proxy:alpine
    labels:
      - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true"
    container_name: nextcloud-proxy
    networks:
      - nextcloud_network
    dns: 
    - 192.168.178.15
    ports:
      - 443:443
      - 80:80
    volumes:
      - ./proxy/conf.d:/etc/nginx/conf.d:rw
      - ./proxy/vhost.d:/etc/nginx/vhost.d:ro
      - ./proxy/html:/usr/share/nginx/html:rw
      - ./proxy/certs:/etc/nginx/certs:rw
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    restart: unless-stopped

  letsencrypt:
    image: jrcs/letsencrypt-nginx-proxy-companion
    container_name: nextcloud-letsencrypt
    depends_on:
      - proxy
    networks:
      - nextcloud_network
    dns: 
      - 192.168.178.15 #need for access the letdyencrypt API
    volumes:
      - ./proxy/acme:/etc/acme.sh
      - ./proxy/certs:/etc/nginx/certs:rw
      - ./proxy/vhost.d:/etc/nginx/vhost.d:rw
      - ./proxy/html:/usr/share/nginx/html:rw
      - /etc/localtime:/etc/localtime:rw
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
        NGINX_PROXY_CONTAINER: "nextcloud-proxy"
        DEFAULT_EMAIL: "mymail@pm.me"
    restart: unless-stopped

  db:
      image: mariadb
      container_name: nextcloud-mariadb
      networks:
        - nextcloud_network
      dns: 
        - 192.168.178.15
      volumes:
        - db-data2:/var/lib/mysql:rw
        - /etc/localtime:/etc/localtime:ro
      environment:
        - MYSQL_ROOT_PASSWORD=Tstrong
        - MYSQL_PASSWORD=Tstrong
        - MYSQL_DATABASE=nextcloud
        - MYSQL_USER=nextcloud
      restart: unless-stopped

  app:
      image: nextcloud:latest
      container_name: nextcloud-app
      networks:
        - nextcloud_network
      depends_on:
        - letsencrypt
        - proxy
        - db
      dns: 
        - 192.168.178.15
        # - 8.8.8.8
      # ports:
      #   - 10000:80 -> makes the app available without nginx and ssl
      volumes:
        - nextcloud-stage:/var/www/html
        - ./app/config:/var/www/html/config
        - ./app/custom_apps:/var/www/html/custom_apps
        - ./app/data:/var/www/html/data
        - ./app/themes:/var/www/html/themes
        - /etc/localtime:/etc/localtime:ro
      environment:
        - VIRTUAL_HOST=mydomain.chickenkiller.com
        - LETSENCRYPT_HOST=mydomain.chickenkiller.com
        - LETSENCRYPT_EMAIL=mymail@pm.me
        - "ServerName=nextcloud"
      restart: unless-stopped

 
volumes:
  nextcloud-stage:
  db-data2:
networks:
  nextcloud_network:
    # external:
      driver: bridge
      name: nginx-proxy

And then it throws this Warning/Info and the SSL does not work. The application would only be available over port 80 if I open the port on this container - which is clearly wrong.

So is this warning actual a problem or do I miss something else?

nextcloud-letsencrypt | ln: failed to create symbolic link '/etc/nginx/certs/mydomain.chickenkiller.com.dhparam.pem': Not supported

I need to specify the DNS so letsencrypt container is able to communicate with the API, so I did point the Docker DNS to my local router 192.168.178.15. Do I need this setting also for the other services? Or is that the problem that breaks the symbolic link?

nextcloud-letsencrypt | [Wed Dec 23 10:47:19 CET 2020] Your cert is in  /etc/acme.sh/mymail@pm.me/mydomain.chickenkiller.com/mydomain.chickenkiller.com.cer 
nextcloud-letsencrypt | [Wed Dec 23 10:47:19 CET 2020] Your cert key is in  /etc/acme.sh/mymail@pm.me/mydomain.chickenkiller.com/mydomain.chickenkiller.com.key 
nextcloud-letsencrypt | [Wed Dec 23 10:47:19 CET 2020] The intermediate CA cert is in  /etc/acme.sh/mymail@pm.me/mydomain.chickenkiller.com/ca.cer 
nextcloud-letsencrypt | [Wed Dec 23 10:47:19 CET 2020] And the full chain certs is there:  /etc/acme.sh/mymail@pm.me/mydomain.chickenkiller.com/fullchain.cer 
nextcloud-letsencrypt | [Wed Dec 23 10:47:19 CET 2020] Installing cert to:/etc/nginx/certs/mydomain.chickenkiller.com/cert.pem
nextcloud-letsencrypt | [Wed Dec 23 10:47:19 CET 2020] Installing CA to:/etc/nginx/certs/mydomain.chickenkiller.com/chain.pem
nextcloud-letsencrypt | [Wed Dec 23 10:47:19 CET 2020] Installing key to:/etc/nginx/certs/mydomain.chickenkiller.com/key.pem
nextcloud-letsencrypt | [Wed Dec 23 10:47:20 CET 2020] Installing full chain to:/etc/nginx/certs/mydomain.chickenkiller.com/fullchain.pem
nextcloud-letsencrypt | ln: failed to create symbolic link '/etc/nginx/certs/mydomain.chickenkiller.com.crt': Not supported
nextcloud-letsencrypt | ln: failed to create symbolic link '/etc/nginx/certs/mydomain.chickenkiller.com.key': Not supported
nextcloud-letsencrypt | ln: failed to create symbolic link '/etc/nginx/certs/mydomain.chickenkiller.com.dhparam.pem': Not supported
nextcloud-letsencrypt | ln: failed to create symbolic link '/etc/nginx/certs/mydomain.chickenkiller.com.chain.pem': Not supported
nextcloud-letsencrypt | Reloading nginx proxy (ac49344ba0acb6026615358abf5568dc6a1df173a308a936b615fa00e413f767)...
nextcloud-letsencrypt | 2020/12/23 09:47:20 Contents of /etc/nginx/conf.d/default.conf did not change. Skipping notification ''
nextcloud-letsencrypt | 2020/12/23 09:47:20 [notice] 115#115: signal process started
nextcloud-letsencrypt | Sleep for 3600s

Nginx throws Error 503 when accessing the application from WAN using the IP (and not the DynDNS) So local port forwarding should also be correct, right? Port 80 and 443 forwarded from Router to NUC

Using DynDNS to access the application from WAN leads to SSL-error (HSTS)

So I think it is just the connection (symbolic link) from the certificate folder to the application?

Let me know if I can provide more information/logs

Cheers

UDPATE:

Here is the NGINX config from /proxy/conf.d/default.conf

# If we receive X-Forwarded-Proto, pass it through; otherwise, pass along the
# scheme used to connect to this server
map $http_x_forwarded_proto $proxy_x_forwarded_proto {
  default $http_x_forwarded_proto;
  ''      $scheme;
}
# If we receive X-Forwarded-Port, pass it through; otherwise, pass along the
# server port the client connected to
map $http_x_forwarded_port $proxy_x_forwarded_port {
  default $http_x_forwarded_port;
  ''      $server_port;
}
# If we receive Upgrade, set Connection to "upgrade"; otherwise, delete any
# Connection header that may have been passed to this server
map $http_upgrade $proxy_connection {
  default upgrade;
  '' close;
}
# Apply fix for very long server names
server_names_hash_bucket_size 128;
# Default dhparam
ssl_dhparam /etc/nginx/dhparam/dhparam.pem;
# Set appropriate X-Forwarded-Ssl header
map $scheme $proxy_x_forwarded_ssl {
  default off;
  https on;
}
gzip_types text/plain text/css application/javascript application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
log_format vhost '$host $remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent"';
access_log off;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
        ssl_prefer_server_ciphers off;
resolver 127.0.0.11;
# HTTP 1.1 support
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
proxy_set_header X-Forwarded-Ssl $proxy_x_forwarded_ssl;
proxy_set_header X-Forwarded-Port $proxy_x_forwarded_port;
# Mitigate httpoxy attack (see README for details)
proxy_set_header Proxy "";
server {
    server_name _; # This is just an invalid value which will never trigger on a real hostname.
    listen 80;
    access_log /var/log/nginx/access.log vhost;
    return 503;
}
server {
    server_name _; # This is just an invalid value which will never trigger on a real hostname.
    listen 443 ssl http2;
    access_log /var/log/nginx/access.log vhost;
    return 503;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_certificate /etc/nginx/certs/default.crt;
    ssl_certificate_key /etc/nginx/certs/default.key;
}
# mydomain.chickenkiller.com
upstream mydomain.chickenkiller.com {
                ## Can be connected with "nginx-proxy" network
            # nextcloud-app
            server 172.23.0.5:80;
}
server {
    server_name mydomain.chickenkiller.com;
    listen 80 ;
    access_log /var/log/nginx/access.log vhost;
    include /etc/nginx/vhost.d/default;
    location / {
        proxy_pass http://mydomain.chickenkiller.com;
    }
}
server {
    server_name mydomain.chickenkiller.com;
    listen 443 ssl http2 ;
    access_log /var/log/nginx/access.log vhost;
    return 500;
    ssl_certificate /etc/nginx/certs/default.crt;
    ssl_certificate_key /etc/nginx/certs/default.key;
}

score 1 · Answer 1 · answered May 08 '21 at 12:21

I had this exact issue. For me, the volume the certificates were being save to was a mounted file share in Azure and those don't support symlinks out of the box.
See: https://learn.microsoft.com/en-us/azure/storage/files/storage-troubleshoot-linux-file-connection-problems.
I am using autofs but adding ",mfsymlinks" to the end of the "fstype" part worked fine once restarted.

Docker-compose nginx with letsencrypt -> ln: failed to create symbolic link - Not supported

1 Answers1