Caddy touble in Docker
from W3dd1e@lemmy.zip to selfhosted@lemmy.world on 07 Jun 21:41
https://lemmy.zip/post/65753092

Howdy! Sorry if this is a supid question. I’ve been trying to get this working for like 5 days and I’ve been researching and reading docs, but I’m just not getting it. I’m fairly new to selfhosing and I’m trying to set up Jellyfin remote access on my NAS. My NAS is a QNAP product running QTS (which I absolutely hate). QTS uses their own weird version of Docker.

When I start Caddy with a docker compose file, I get an error that port 443 is in use and the container can’t be started. If I create a container in the Container Station app directly from the Docker Image, it starts up fine. Container Station handles environment variables in a dumb way so I am having trouble specifying the Caddyfile location when I do it that way.

Does anyone know why it works fine in that way but not the other? Both use port 443 but when I do it in a docker compose file, it says the port is in use but when I do it the other way, it doesn’t and starts fine.

Note: I know you can do this with Tailscale also, but I want to use my custom domain to make it easier for sharing in the future.

#selfhosted

threaded - newest

doeknius_gloek@discuss.tchncs.de on 07 Jun 21:49 next collapse

Is your Caddy actually reachable on port 443 when you use the Container Station App?

My first thought was that your NAS might use port 443 for its own web ui?

damnthefilibuster@lemmy.world on 07 Jun 22:03 next collapse

Yeah, most likely the Compose version is aware of the ports in use and 443 is pretty standard for the NAS to keep to itself. The direct docker process would not be aware of the default config, or env Vars.

Also, welcome to Selfhosing! 😂

W3dd1e@lemmy.zip on 07 Jun 22:49 collapse

Yes it works fine if I build the container from The imagine directly inside the container station app, but I’m having trouble pointing that to the Caddyfile.

If I try to create the container from a docker compose file, it says it can’t bind to port 443 because it’s already in use.

irmadlad@lemmy.world on 07 Jun 22:09 next collapse

When I start Caddy with a docker compose file,

So, I’ve never owned a QNAP product running QTS nor have I run Caddy in a Docker container before, but I am assuming it looks something similar to this:

spoiler

networks: proxy-network: external: true services: caddy: image: caddy container_name: caddy restart: unless-stopped ports: - 80:80 - 443:443 volumes: - ./data:/data - ./config:/config - ./Caddyfile:/etc/caddy/Caddyfile:ro networks: - proxy-network

Have you tried changing the port #:

    ports:
      - 80:80
      - 4443:443

ETA:

I’m fairly new to selfhosing

Welcome to the club bro. You’re in the right place.

W3dd1e@lemmy.zip on 07 Jun 22:53 collapse

Yeah, I can do that. I just wanted to understand why it work sometimes but not others.

I HATE QTS. It’s all proprietary software and it’s locked down so I can’t use CLI at all unless I SSH into it. And when I do that, I still can’t add 3rd party software that isn’t in their App Store because there is no apt, dnf, brew, or other similar tools.

I’ve been considering trying to install TrueNAS or something else on it but it sounds like that will be a hassle too because the fans don’t want to work.

irmadlad@lemmy.world on 07 Jun 23:10 next collapse

Yeah, I can do that. I just wanted to understand why it work sometimes but not others.

It’s been a few minutes since I’ve run Caddy, and like I mentioned, I don’t own a QNAP. So, I’m just spitballing.

theit8514@lemmy.world on 07 Jun 23:18 next collapse

If I had to guess, the container station might be giving the docker container a new network/ip address, one that the NAS is not using so that port 443 works and doesn’t conflict with the NAS. If you start the container station then inspect the container you might see how they do it, but macvlan is typically how you would configure it.

services:
  my-lan-service:
    image: nginx:latest
    container_name: lan_container
    # 1. Attach the service to the custom macvlan network
    networks:
      lan_network:
        ipv4_address: 192.168.1.200  # The dedicated LAN IP for this container
    # 2. Ports are exposed directly to the LAN; do NOT use the "ports" block
    restart: unless-stopped

networks:
  lan_network:
    driver: macvlan
    driver_opts:
      parent: eth0                  # Change to your host's physical network interface name
    ipam:
      config:
        - subnet: 192.168.1.0/24    # Matches your physical local network setup
          gateway: 192.168.1.1      # Your physical router IP
minoche@lemmy.world on 08 Jun 07:07 collapse

I still can’t add 3rd party software that isn’t in their App Store

That doesn’t seem right… I think you can use their “Container Station” to make an LXD or Docker container with whatever you want. You may have to enable “advanced mode.” www.qnap.com/…/how-to-use-container-station-3

DonutsRMeh@lemmy.world on 07 Jun 23:09 next collapse

NASes are so annoying. I had so many issues with my Synology NAS with plex and jellyfin. I ended up spinning up a debian server on a small Dell optiplex micro and then mounted my Nas as storage through debian. Installed Jellyfin as a normal debian package. No docker or anything like that. I’ve never used (or even heard of) QNAP, but are you able to reach it through SMB? If you can, then you can do it like I did

billwashere@lemmy.world on 07 Jun 23:13 next collapse

This probably doesn’t help you much right now but I have a QNAP as well. And I too despise the QTS software. But I found out that TrueNAS can run on it pretty easily. I have an NVME drive on a usb-c enclosure that I installed trueNAS on and it boots fine into it. If I ever wanna go back it’s just a remove the boot drive and reformat (the ZFS pools are compatible unfortunately).

W3dd1e@lemmy.zip on 07 Jun 23:32 collapse

Actually I’ve been strongly considering swapping the OS to TrueNAS but I’ve heard some people have trouble with getting the fans to work once they switched over. If you’ve had a good experience I’m willing to give it a shot.

kylian0087@lemmy.dbzer0.com on 08 Jun 08:05 collapse

Their is a driver to get fans working or at least usable. github.com/0xGiddi/qnap8528

To build the driver you usually have to enable Dev mode on truenas scale. I did not want to this so I made a container which can build the driver for you. This way you do not need to enable Dev mode and their for remove the write protection on the host OS. github.com/kylian-002/Truenas-qnap8528-module

ryannathans@aussie.zone on 07 Jun 23:30 next collapse

You need root to bind to the first thousand ports, is it possible your container station is running as root or something to that effect? Does it work correctly when the port number is some other large number like 8921?

W3dd1e@lemmy.zip on 07 Jun 23:35 collapse

It works fine with other ports, including 8443 and 444. It works in Container Station with 443 if I don’t use a Docker Compose file. The whole thing makes no sense.

I checked to see what was using 443 but all I get is “containerd”. I couldn’t find anymore info on what or why Containerd would be using that and no other containers are running.

ryannathans@aussie.zone on 08 Jun 03:10 collapse

Probably some proprietary interface the NAS provider set up

surewhynotlem@lemmy.world on 08 Jun 01:28 next collapse

“In QNAP QTS, Port 443 is the default secure port for,…”

If it says it’s already in use it’s because it’s already in use. Try changing the QNAP management UI port.

carlnewton@feddit.uk on 08 Jun 08:28 collapse

Hey, I’m just guessing here because I haven’t used Caddy in Docker directly, but I do manage a project that uses FrankenPHP, which is essentially a wrapper for Caddy as I understand it, and I’ve had a problem that looks similar to this.

Caddy will attempt to generate an SSL certificate, and if you are using a reverse proxy, depending on how it’s configured, it will internally attempt to fulfil that certificate generation over port 443, which will fail, because it doesn’t have a configured SSL certificate. It’s the old catch-22!

The solution I have found is to temporarily internally serve your environment over port 80 for external SSL connections. This will allow Caddy to retrieve an SSL certificate and put it in place. After this, you should then be able to switch back over to port 443 for SSL connections internally, and it’ll use the certificate.

Once again – this is just a guess, and I don’t know the exact criteria in getting this going in Caddy, but it might be worth a try. In my FrankenPHP project at least, it was a matter of setting the SERVER_NAME variable to http://${DOMAIN}:80