From 69c7a4cc19073c5f7c4d9b9429af9403ba1639d9 Mon Sep 17 00:00:00 2001 From: manzuoni-astera Date: Wed, 12 Aug 2026 13:28:23 -0400 Subject: [PATCH] fix(astera): keep pixi's cache off the NFS home volume MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Any environment with a git dependency fails to solve in an ACTL workspace. protpardelle is the one people hit: failed to solve the pypi requirements of environment 'protpardelle-dev' ... fatal: detected dubious ownership in repository at '/home/dev/.cache/rattler/cache/uv-cache/git-v0/db/' ACTL mounts $HOME from an nfs-shared PVC whose export squashes every write to nobody (65534) while the container runs as root, so uv's git cache — which pixi places under its own cache dir — ends up in a tree root does not own, and git refuses to operate on it. Confirmed on the reporting pod: that directory is owned by 65534 and $HOME is the NFS PVC. Pointing the cache root at container-local disk makes root the owner and the clone succeeds. Verified the git cache then lands at /var/cache/pixi/uv-cache/git-v0 owned by uid 0. git config is not a usable fix here. This image ships git 2.34.1, where only an exact path or the bare `*` is honoured — prefix globs such as /home/dev/.cache/* are silently ignored (tested all four forms). Cache paths are content-hashed so exact entries are whack-a-mole, and `*` would also disable the ownership check on genuinely shared volumes like /mnt/diffuse-shared. UV_CACHE_DIR does not work either: pixi ignores it and keeps the uv cache under its own root (tested). pixi already redirects its repodata and pypi-mapping caches off network filesystems by itself and warns while doing so; it just does not extend that to the uv cache. This applies the same treatment to all of them. Trade-off: the download cache no longer survives a pod restart. Environments live in the synced checkout and are unaffected. --- Dockerfile.astera | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/Dockerfile.astera b/Dockerfile.astera index c159a837..e206195e 100644 --- a/Dockerfile.astera +++ b/Dockerfile.astera @@ -30,7 +30,34 @@ ENV DEBIAN_FRONTEND=noninteractive \ SAMPLEWORKS_PIXI_PROJECT_DIR=/app \ SAMPLEWORKS_REQUIRE_PREBUILT_PIXI=1 \ SAMPLEWORKS_SKIP_ENV_PREPARE=1 \ - EXT_REPLAY_BASE_IMAGE=${PIXI_WITH_CHECKPOINTS_IMAGE} + EXT_REPLAY_BASE_IMAGE=${PIXI_WITH_CHECKPOINTS_IMAGE} \ + PIXI_CACHE_DIR=/var/cache/pixi + +# Keep pixi's cache off the NFS-backed home volume. +# +# ACTL mounts $HOME from an nfs-shared PVC whose export squashes every write to +# nobody (65534), while the workspace container runs as root. pixi puts uv's git +# cache under its own cache dir, so a `git+https://` dependency gets cloned into +# a tree root does not own, and git refuses to touch it: +# +# fatal: detected dubious ownership in repository at +# '/home/dev/.cache/rattler/cache/uv-cache/git-v0/db/' +# +# which surfaces as an unrelated-looking "failed to solve the pypi requirements" +# and blocks any environment with a git dependency (protpardelle, today). +# +# `git config --global --add safe.directory` is not a usable fix here: this +# image ships git 2.34.1, where only an exact path or the bare `*` is honoured — +# prefix globs are silently ignored (verified). The cache paths are +# content-hashed, so exact entries are whack-a-mole, and `*` would disable the +# ownership check on genuinely shared volumes like /mnt/diffuse-shared too. +# +# pixi already redirects its repodata and pypi-mapping caches off network +# filesystems on its own; it just does not do the same for the uv cache. Setting +# the cache root to container-local disk covers all of them. The trade-off is +# that the download cache no longer survives a pod restart — environments +# themselves live in the synced checkout and are unaffected. +RUN mkdir -p /var/cache/pixi RUN apt-get update && apt-get install -y --no-install-recommends \ bash \