Repository navigation
Conversation
…e expected filesystem Volume create does os.MkdirAll on the path derived from PERSISTENT_VOLUME_MOUNTS assuming local disk. When an operator intends a distributed filesystem (JuiceFS, CephFS, GlusterFS, SeaweedFS, BeeGFS, ...) for volumes but it is not actually mounted, MkdirAll silently creates the volume on the local root disk: the create "succeeds", data is not shared across sandboxes, and the failure only surfaces later when the local disk fills. Add an optional guard: VOLUME_EXPECTED_FSTYPE. When set, CreateVolume verifies, before MkdirAll, that the volume path is on a mount of that filesystem type (read from /proc/mounts, matching the longest mount-point prefix so a not-yet- created leaf resolves to its enclosing mount), and fails fast otherwise. Empty (the default) keeps today's local behavior with no mount check, so this is a no-op unless opted in. Distilled minimal core of the earlier e2b-dev#3196: that PR added a six-backend plugin framework (local/juicefs/cephfs/glusterfs/seaweedfs/beegfs, 22 files, ~1338 lines), but the five distributed backends were identical wrappers differing only in the /proc/mounts fstype string they check - every one delegated create/delete to the same directory operations. The real, non-speculative value is exactly that mount-type verification, which this implements in one file + test and one config field, without the backend zoo or any default behavior change. The broader pluggable-backend design is left to the maintainers (issue e2b-dev#3195 stays open). Tests cover fstype resolution (inside mount, mount point itself, prefix-colliding sibling, fallback to root, root), and the guard (no-op when unset, pass on expected fs, reject when the distributed FS is not mounted and the path lands on the local root, reject wrong fstype, error on missing mounts file). Relates to e2b-dev#3195. Distills e2b-dev#3196.
AdaAibaby
requested review from
ValentaTomas,
dobrac and
jakubno
as code owners
October 23, 2026 05:54
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Distilled minimal core of #3196 (closed inactive). Instead of re-proposing that PR's six-backend plugin framework, this ships only the part with concrete, non-speculative value — and leaves the broader pluggable-backend design to the maintainers.
Problem (still on
main)CreateVolumedoesos.MkdirAllon the path derived fromPERSISTENT_VOLUME_MOUNTS, assuming local disk (volume_create.go→ rawos.MkdirAll(fullPath, 0o700)). When an operator intends a distributed filesystem (JuiceFS, CephFS, GlusterFS, SeaweedFS, BeeGFS, …) for volumes but it is not actually mounted,MkdirAllsilently creates the volume on the local root disk: the create "succeeds", data isn't shared across sandboxes, and the failure only surfaces later when the local disk fills.Fix
Optional
VOLUME_EXPECTED_FSTYPE. When set,CreateVolumeverifies — beforeMkdirAll— that the volume path is on a mount of that filesystem type (read from/proc/mounts, matching the longest mount-point prefix so a not-yet-created leaf resolves to its enclosing mount), and fails fast otherwise. Empty (the default) keeps today's local behavior with no mount check — a no-op unless opted in.Why only this, not #3196's six backends
#3196 added a
local/juicefs/cephfs/glusterfs/seaweedfs/beegfsbackend framework (22 files, ~1338 lines). But the five distributed backends were identical wrappers over a sharedMountpointBackend, differing only in the/proc/mountsfstype string checked inHealthy()— every one delegated create/delete to the same directory operations. The real value is exactly that mount-type verification; it's implemented here in one file + test and one config field, no backend zoo, no default behavior change. The broader design is left for maintainer direction — #3195 stays open.Tests
mountFSTypeFrom: inside mount, mount point itself, prefix-colliding sibling (/mnt/jfsvs/mnt/jfs-backup), fallback to root, root.verifyVolumeMountFrom: no-op when unset; pass on expected fs; reject when the distributed FS isn't mounted and the path lands on the local root (the footgun); reject wrong fstype; error on missing mounts file.4 files, +184.
go build ./...andgo vetpass.Relates to #3195. Distills #3196.