# /enable 500 on share creation

**URL:** <https://openziti.discourse.group/t/enable-500-on-share-creation/6069>\
**Category:** zrok\
**Created:** [September 9, 2026, 6:38am UTC](https://openziti.discourse.group/t/enable-500-on-share-creation/6069 "2026-09-09T06:38:09Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![blik616287](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/blik616287/32/4285_2.png) [@blik616287](https://openziti.discourse.group/u/blik616287)\
**Post date:** [September 9, 2026, 6:38am UTC](https://openziti.discourse.group/t/enable-500-on-share-creation/6069/1 "2026-09-09T06:38:09Z")

</div>

**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

```auto
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

```auto
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

---

<div class="post-metadata">

**Author:** ![GiperKot007](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/giperkot007/32/4327_2.png) [@GiperKot007](https://openziti.discourse.group/u/GiperKot007)\
**Post date:** [September 9, 2026, 6:56am UTC](https://openziti.discourse.group/t/enable-500-on-share-creation/6069/2 "2026-09-09T06:56:16Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![blik616287](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/blik616287/32/4285_2.png) [@blik616287](https://openziti.discourse.group/u/blik616287)\
**Post date:** [September 9, 2026, 8:41am UTC](https://openziti.discourse.group/t/enable-500-on-share-creation/6069/3 "2026-09-09T08:41:20Z")

</div>

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