Share persistence between restarts

[deevus]

I'm running copyparty in docker. If I create a share and then restart the container, the share URL doesn't work anymore.

Here is the relevant section from my docker-compose.yml:

  copyparty:
    image: copyparty/ac:latest
    container_name: copyparty
    restart: unless-stopped
    depends_on:
      - caddy
    network_mode: service:tailscale
    environment:
      - TZ=Australia/Sydney
    volumes:
      - ${config_path}:/cfg
      - ${builds_path}:/data/builds
      - ${hist_path}:/hist

And my copyparty.conf:

# CopyParty configuration
# https://github.com/9001/copyparty

[global]
  # Enable file indexing and multimedia metadata
  e2dsa
  e2ts

  # Store databases, thumbnails, and metadata in /hist (persisted volume)
  hist: /hist

  # Enable share links at /.share (matches public Caddy route)
  shr: /.share

  # Enable colors in logs
  ansi

  # Trust reverse proxy headers from localhost and LAN
  xff-src: lan

  # Authentik header-based IdP authentication
  # Caddy passes these headers after forward auth
  idp-h-usr: X-authentik-username
  idp-h-grp: X-authentik-groups

  # Listen on all interfaces (Caddy sidecar handles external access)
  i: 0.0.0.0
  p: 3923

[accounts]
  # CI/CD account for API uploads (local account, not SSO)
  cicd:${api_token}

[/builds]
  # Build artifacts directory
  /data/builds

  # Access control:
  # - Authenticated users (admins, staff, family) can read
  # - Admins have full access (read, write, move, delete, admin)
  # - CI/CD account can write
  # - Share links handle their own access for public users
  accs:
    r: @admins, @staff, @family
    rwmda: @admins
    w: cicd

[deevus]

Ok this is weird.

Step 1: Restart copyparty

Step 2: Go to share

Step 3: Go to shares page

Step 4: Go to share

So I think this is a bug.

[9001]

can you post the full copyparty log of that entire sequence, starting from the most recent restart of the container, so it includes those three requests you sent?

[deevus]

Yep I will do this when I get a chance

[deevus]

I'm using two reverse proxies, so I need to rule that out as an issue first. Is this a supported use case?

Basically I have an internal tailscale address for copyparty, and a public internet facing one that only allows the .share/ and .cpr/ routes.

[9001]

I'm using two reverse proxies, so I need to rule that out as an issue first. Is this a supported use case?

yes, assuming they have both been configured correctly -- the two reverseproxies must be configured so that they send exactly identical headers regarding client-IP info (rproxy and the xf options), and the request paths must also be identical. Further, the LAN-IP subnets of both proxies must be added to xff-src. All of this should be obvious by looking at the copyparty log with ihead: *