Release date: July 31, 2026. Repository: owncloud/ocis. Tag: v8.0.7.
ownCloud Infinite Scale (oCIS) 8.0.7 fixes two bugs and adds three enhancements, all in the graph/LDAP and webdav services. The headline items are a correctness fix to the /graph/v1.0/me endpoint’s identity reporting and an opt-in bounded connection pool for LDAP-backed graph and auth services.
Fixed: correct issuerAssignedId on /me (#12635)
The /graph/v1.0/me endpoint reports a user’s identities, including issuerAssignedId — the identifier assigned by the external identity provider, typically the OIDC sub claim. Before 8.0.7, a fast path in the endpoint built the user model directly from the CS3 user object already present in the request context. That object does not carry the external identity, so the endpoint fell back to reporting the user’s internal oCIS UUID in the issuerAssignedId field instead of the issuer-assigned value.
8.0.7 removes that fast path: /me now always resolves the user through the identity backend, which holds the stored external identity, and returns the correct issuerAssignedId. This matters for any client or integration that reads /me to correlate an oCIS user with an external identity provider’s subject identifier: provisioning scripts or SSO-adjacent tooling that match users by OIDC sub rather than oCIS’s internal UUID. Group membership expansion behavior is unchanged: memberships are still only included when the caller requests $expand=memberOf.
Fixed: unmapped thumbnail errors now logged, sabredav exception always returned (#12663)
The webdav service previously logged failures from the thumbnails service only at debug level. For error conditions that are not a property of the requested file itself, the thumbnails service being unreachable, for instance, this meant a complete preview outage could produce a wall of HTTP 500 responses without a single log line at production log levels explaining why: one production incident behind this fix generated roughly 1,700 unexplained HTTP 500s a day for six days. Expected per-file outcomes, such as an unsupported file type or a file still being processed, are unaffected and correctly stay at debug level; it’s only the unmapped, unexpected failures that were invisible before this fix. Two of the four thumbnail handlers also logged without the request context attached, so on the rare occasion something did get logged, it carried no request ID to trace it by.
8.0.7 logs unmapped thumbnail errors at error level and attaches the request context to all four handlers. Separately, the webdav layer’s status-code-to-exception mapping (codesEnum) previously covered only four HTTP status codes; every other code rendered as an empty, unhelpful <s:exception></s:exception> element. 8.0.7 adds the missing mappings for HTTP 403, 425, and 429, and, more importantly, gives any other unmapped code a generic fallback exception name, so a sabredav client always receives a usable, non-empty exception regardless of which status code comes back.
Enhancement: eliminate redundant LDAP read-after-write on create and update (#12618)
The graph LDAP backend previously re-read an entry from the directory immediately after writing it, solely to recover the entry ID for the response. When oCIS generates the entry’s ID itself (GRAPH_LDAP_SERVER_UUID disabled, the default), that re-read returns nothing new: 8.0.7 synthesizes the create response from the data already sent to the directory, and builds update responses by folding the applied modifications onto the entry that was already read before the write, removing one LDAP round trip per write operation. When the directory assigns the ID instead (GRAPH_LDAP_SERVER_UUID enabled), creates keep the existing read-back, since a directory-assigned ID can’t be recovered any other way.
For deployments with LDAP directories under load, reached through a proxy, or with higher round-trip latency, this reduces the number of requests graph operations issue per user or group create/update, and removes a read that could previously land on a lagging replica and fail or return stale data.
Enhancement: opt-in bounded LDAP connection pool (#12660)
The auth-basic, users, groups, and graph services can now use a bounded connection pool instead of a single long-lived LDAP connection. This is opt-in, controlled by OCIS_LDAP_POOL_ENABLED (or a service-specific _LDAP_POOL_ENABLED override), with two tuning variables:
- OCIS_LDAP_POOL_SIZE — maximum pool size, default 5
- OCIS_LDAP_POOL_CHECKOUT_TIMEOUT — how long a request waits for a pooled connection before failing, default 30s
Pooled connections are dialed and bound lazily on checkout rather than held open eagerly, and an unhealthy connection is discarded and lazily re-dialed rather than proactively reconnected. A single long-lived connection can become a bottleneck under concurrent load, or can leave a service without a working LDAP connection if that one connection drops; a bounded pool lets oCIS serve concurrent LDAP-backed requests over multiple connections, with the pool size capping how many the directory server has to sustain at once. As part of this change, the graph service’s identity backend now shares the same LDAP client implementation used by the reva auth/user/group managers, instead of maintaining its own separate reconnecting client. Because pooling is opt-in, existing deployments are unaffected unless an administrator explicitly sets OCIS_LDAP_POOL_ENABLED.
Enhancement: configurable retry for LDAP operations against a lagging replica (#12672)
The graph LDAP backend has always retried an operation once, immediately, with no delay, as a hardcoded default. 8.0.7 makes that retry behavior configurable, for deployments running LDAP behind a load balancer or a multi-master/read-replica topology where a read shortly after a write can land on a replica that hasn’t caught up yet, most notably the read-back that recovers a directory-assigned ID after a create. Retry count and backoff are now tunable through OCIS_LDAP_RETRY_MAX_COUNT (or the service-specific GRAPH_LDAP_RETRY_MAX_COUNT override), OCIS_LDAP_RETRY_BASE_DELAY, and OCIS_LDAP_RETRY_MAX_DELAY; the max-count default is 1 retry, reproducing the previous single-immediate-retry behavior, so deployments that don’t set these variables see no change.
The more important fix here is a correctness one, and it took a real back-and-forth in review to land correctly. Reads retry broadly on network and transient errors, same as before. Writes are more delicate: an initial version of this change would have stopped retrying writes on any network error, on the theory that a network error can surface after the request already reached the server, in which case retrying could double-apply the mutation. Code review caught that this went too far, with a reproduction script to prove it: because of how the underlying LDAP library reports errors, that overly broad rule meant writes effectively never retried at all, even in the common, safe case of a stale idle connection that was never used to send anything. The version that shipped is narrower and correct: a write retries only when the connection is confirmed to have failed before the request was sent, so the retry can never land on a mutation that may have already reached the server.
Upgrade Notes
None of the five changes in 8.0.7 require a data migration or a change to existing configuration to pick up the fixes: the two bugfixes apply automatically. The LDAP connection pool is genuinely new and opt-in, defaulting to the previous single-connection behavior when OCIS_LDAP_POOL_ENABLED is unset. The LDAP retry logic already existed before 8.0.7; its defaults are unchanged, and the new environment variables only make it configurable, they don’t turn on behavior that wasn’t there before. Administrators running LDAP behind a connection-sensitive proxy or a replicated directory are the primary audience for both LDAP environment variable groups above and should review whether enabling or tuning them fits their topology.
Credit Where It’s Due
A lot of people worked to make this possible. Thanks to everyone who contributed, especially:
Julian Koberg (kobergj) is behind both bugfixes in this release: the /me identity resolution fix and the thumbnail error-logging fix.
Roman Perekhod (2403905) eliminated the redundant LDAP read-after-write, and also did the review work that caught the write-retry regression described above before it shipped. Lukas Hirt (LukasHirt), a familiar name from oCIS’s extension work, built the opt-in connection pool and unified the graph service’s LDAP client with reva’s.
Michal Klos (mklos-kw) built the retry policy and, working with that review feedback, landed the narrower, correct version.
One reviewer on the read-after-write PR put it well: this closes the LDAP round trip at the graph layer, and the same pattern further up the stack is fair game for a future pass.
This post was generated from the GitHub Release description for oCIS 8.0.7, cross-checked directly against pull requests #12635, #12663, #12618, #12660, and #12672. The release family for oCIS relies on a maintainer-written Release body rather than a CHANGELOG.md file at the tag. Read it directly at github.com/owncloud/ocis/releases/tag/v8.0.7.
ownCloud OSPO: moc.skrowetik@opso · kiteworks.com/opensource
