/enable 500 on share creation

zrok
1

Share creation fails for every share type and every
environment on the account, while all reads succeed.

One thing up front so nobody chases the wrong thing: the shares on this account
were deleted by our own tooling (a health-check script that called
zrok release on transient API failures — our bug, now fixed). That part is not
on zrok. The problem is that we cannot recreate anything afterwards.

Account

  • Hosted email: mforde84@gmail.com
  • Controller: GET /api/v2/versions → {"controllerVersion":"v2.0.4 [6ff92039]"}
  • 8 environments, 0 shares on every one (confirmed via both
    GET /api/v1/overview and GET /api/v2/overview)

Environments, including two duplicate-host pairs that match the "dual
environments" signature in the original report:

description zId created
blik@blik V0qHEfvcIK 2026-08-10
ubuntu@isc-jump-vm-2 aS2mmDtadH 2026-01-15
root@gx10-9cd0 gO0Xf2IG6 2026-02-24
ubuntu@lab103-jump-vm-1 cHgbrW2h6R 2026-03-16
blik@spaceship S376-Rwhdm 2026-03-18
b@gx10-9cd0 .DaNXsEhdr 2026-06-05
android@localhost x-GCLOxo7j 2026-07-13
android@localhost eViNDsxo7j 2026-07-17

gx10-9cd0 is enrolled twice (root@ and b@), and android@localhost
appears twice.

Clients tested

  • zrok v1.1.11 (deb, zitipax-openziti-deb-stable) → api-v1.zrok.io
  • zrok v2.0.4 (GitHub tarball, clean isolated HOME, no prior state) →
    api-v2.zrok.io

Both fail identically, and the controller is itself v2.0.4, so this is not a
client/controller version skew.

What fails — all with an empty response body

POST /enable   [500] enableInternalServerError    (v2.0.4 client, fresh HOME)
POST /share    [500] shareInternalServerError     (reserved, v1.1.11 CLI)
POST /share    [500] shareInternalServerError     (ephemeral:
                                                   zrok share private --backend-mode tcpTunnel localhost:22)
POST /api/v2/share [500] ""                       (raw, tried with envZId
                                                   S376-Rwhdm / .DaNXsEhdr / gO0Xf2IG6)
DELETE /unshare [404] unshareNotFound

Ephemeral shares are worth calling out: they skip the reserved-name path
entirely and still 500, so this does not look like a unique-name collision.

What works

GET /api/v1/overview              200
GET /api/v2/overview              200   (0 shares)
GET /api/v2/detail/account        200
GET /api/v2/detail/environment/*  200
GET /api/v2/versions              200

Auth is fine — the account token authenticates against both API versions.

Controller instability leading up to it

Errors logged by one host against api-v1.zrok.io over roughly four weeks,
during clientVersionCheck:

response count
502 37
503 26
504 22

At the time the shares vanished, an established zrok share reserved tunnel had
been up 5d17h and was still passing traffic, with zero Ziti-side errors
logged — no "service not found", no bind failures. The share row disappeared
from the controller while the underlying Ziti service kept working, which looks
like the same DB/Ziti divergence described in the original report.

Ask

Could someone inspect the controller/Ziti state for this account and reconcile
it — in particular the duplicate environment rows above and any dangling Ziti
identities/service policies they left behind — so that POST /share works
again? We are deliberately not retrying in a loop.

Separately: the empty response body on these 500s makes them undiagnosable from
the client side. Even a correlation ID would help a lot.

Also worth noting status.zrok.io shows "All systems operational" throughout.S

2

I have the same problem, and many people have already started threads about it; this has been going on for about a week now. Lots of similar threads have been created, but no one is replying. It’s very frustrating.

3

looks like the endpoint is back for me. atleast intermittently. will confirm tomorrow. thanks guys.