Error: [POST /share][500] shareInternalServerError) (But only with a specific share domain)

zrok
1

I am using Zrok2, I had set it up in podman to share my reserved name and after I restarted my computer with the podman container running, I would get an error when trying to start container again that the name was already in use. So, I tried deleting the reserved name and then creating it again. Creating it worked, but when I try to share with it I get the error: [ERROR]: unable to create share (unable to create share: [POST /share][500] shareInternalServerError)

This only now happens with this specific share domain and if I create a new name it works fine.

2

Welcome to the forum, @wendellmeset!

Will you share a verbatim, except redactions, snippet of your configuration, please, e.g., compose file if you're using that? If you're using a Docker Compose project file with Podman, then it'll help me if I can see more precisely how you're sharing a reserved name.

Are you working with the Docker agent guide from this area of the docs (zrok agent | NetFoundry Documentation)?

3

I have also tried sharing the reserved share on my Windows laptop and a bare metal Linux install, it seems the issue is not with Podman but rather with that specific reserved share.

Nonetheless, here is the podman container (I assume this is not the intended way of doing it but it did work before it broke):

# podman-compose.yml
version: "3.9"

services:
  redacted:
    build:
      context: .
      dockerfile: Containerfile
    container_name: redacted
    restart: always
    cpus: '2.0'
    mem_limit: 512m
    volumes:
      - ./backend/data:/app/backend/data
      - zrok_home:/root/.zrok2
volumes:
  zrok_home:

Entrypoint.sh:

#!/bin/bash
set -e

echo "=== [REDACTED] Container Starting ==="

export ZROK_HOME=/root/.zrok2

echo "[zrok] Enabling environment with token..."

ENABLE_OUTPUT=$(zrok enable --headless [REDACTED_TOKEN] 2>&1) || true

if echo "$ENABLE_OUTPUT" | grep -q "already have an enabled environment"; then
    echo "[zrok] Environment already enabled, skipping."
else
    echo "$ENABLE_OUTPUT"
fi

echo "[REDACTED] Starting backend..."
cd /app/backend
./backend &
BACKEND_PID=$!

echo "[REDACTED] Waiting for backend on port 8080..."
for i in $(seq 1 30); do
    if curl -sf http://localhost:8080 > /dev/null 2>&1; then
        echo "[REDACTED] Backend is up."
        break
    fi
    sleep 1
done

echo "[zrok] Starting public share on localhost:8080..."
zrok share public localhost:8080 -n public:[REDACTED] --headless &
ZROK_PID=$!

cleanup() {
    echo "[shutdown] Stopping processes..."
    kill $ZROK_PID 2>/dev/null || true
    kill $BACKEND_PID 2>/dev/null || true
    wait
    echo "[shutdown] Done."
}
trap cleanup SIGTERM SIGINT

wait $BACKEND_PID

Containerfile:

FROM golang:1.23-bookworm AS builder

WORKDIR /app

COPY . .

WORKDIR /app/backend
RUN go mod download
RUN CGO_ENABLED=1 GOOS=linux go build -o backend_binary ./main.go


FROM debian:bookworm-slim

RUN apt-get update && apt-get install -y \
    ca-certificates \
    wget \
    curl \
    tar \
    sqlite3 \
    dos2unix \
    gnupg \
    && rm -rf /var/lib/apt/lists/*

RUN curl -sSfL [REDACTED_URL] \
    -o /usr/local/bin/zrok \
    && chmod +x /usr/local/bin/zrok

WORKDIR /app

COPY --from=builder /app/backend/backend_binary ./backend/backend_binary

COPY backend/config/ ./backend/config/

COPY backend/data/ ./backend/data/

COPY frontend/ ./frontend/

COPY entrypoint.sh /entrypoint.sh
RUN dos2unix /entrypoint.sh && chmod +x /entrypoint.sh

EXPOSE 8080

ENTRYPOINT ["/entrypoint.sh"]
4

The backend HTTP check is a nice touch. Is that the main reason you made your own container image, entrypoint, etc?

The vended image includes a zrok2-enable entrypoint that enables the account in ~/.zrok2 unless it is already enabled.

I suspect zrok2 didn't have an opportunity to gracefully shut down and unshare that name selection, so there was a name conflict the next time you tried to share the same name.

The zrok2 agent (Docker guide here) is intended to handle this for you, as long as it shuts down gracefully then it should unshare, making the name selection available for the next run. Did you encounter a problem with a name conflict using the agent in a container?