# MinIO AIStor Memory RELEASE.2026-09-04T23-47-52Z Released: 2026-09-05 Two write-path fixes. A file that is created and then reopened for writing no longer fails with `Resource busy`, so Python installers can build a virtualenv on a mount; and an in-place rewrite of an existing file no longer loses its writes. --- ## Downloads ### Binaries | Platform | Architecture | Download | | -------- | ------------ | ----------------------------------------------------------------------------------------------------------------------- | | Linux | amd64 | [aimem.RELEASE.2026-09-04T23-47-52Z](https://dl.min.io/aistor/aimem/release/linux-amd64/archive/aimem.RELEASE.2026-09-04T23-47-52Z) | | Linux | arm64 | [aimem.RELEASE.2026-09-04T23-47-52Z](https://dl.min.io/aistor/aimem/release/linux-arm64/archive/aimem.RELEASE.2026-09-04T23-47-52Z) | The setuid `aimem-fusermount` mount helper and the `aimem-bio` sibling that `aimem bio` dispatches to are published beside it: | Binary | Architecture | Download | | ------------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | `aimem-fusermount` | amd64 | [aimem-fusermount.RELEASE.2026-09-04T23-47-52Z](https://dl.min.io/aistor/aimem/release/linux-amd64/archive/aimem-fusermount.RELEASE.2026-09-04T23-47-52Z) | | `aimem-fusermount` | arm64 | [aimem-fusermount.RELEASE.2026-09-04T23-47-52Z](https://dl.min.io/aistor/aimem/release/linux-arm64/archive/aimem-fusermount.RELEASE.2026-09-04T23-47-52Z) | | `aimem-bio` | amd64 | [aimem-bio.RELEASE.2026-09-04T23-47-52Z](https://dl.min.io/aistor/aimem/release/linux-amd64/archive/aimem-bio.RELEASE.2026-09-04T23-47-52Z) | | `aimem-bio` | arm64 | [aimem-bio.RELEASE.2026-09-04T23-47-52Z](https://dl.min.io/aistor/aimem/release/linux-arm64/archive/aimem-bio.RELEASE.2026-09-04T23-47-52Z) | Every binary is published alongside `.sha256sum`, `.minisig`, and `.asc` files at the same path. These links point into `archive/`, which is where a release's artifacts stay once a newer release ships, so they keep resolving to this build. The unversioned `…/linux-{arch}/aimem` path always serves the newest release, which is a different binary as soon as one follows this. ### Packages `.deb`, `.rpm`, and `.apk` install the `aimem` client plus the setuid `aimem-fusermount` mount helper (`/usr/bin/aimem-fusermount`, mode 4755) and the `aimem-bio` sibling. They also drop a disabled example `mnt-aimem.mount` systemd unit and create the `/sbin/mount.aimem` helper it needs. | Format | Architecture | Download | | ------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | DEB | amd64 | [aimem\_20260904234752.0.0_amd64.deb](https://dl.min.io/aistor/aimem/release/linux-amd64/archive/aimem_20260904234752.0.0_amd64.deb) | | DEB | arm64 | [aimem\_20260904234752.0.0_arm64.deb](https://dl.min.io/aistor/aimem/release/linux-arm64/archive/aimem_20260904234752.0.0_arm64.deb) | | RPM | amd64 | [aimem-20260904234752.0.0-1.x86_64.rpm](https://dl.min.io/aistor/aimem/release/linux-amd64/archive/aimem-20260904234752.0.0-1.x86_64.rpm) | | RPM | arm64 | [aimem-20260904234752.0.0-1.aarch64.rpm](https://dl.min.io/aistor/aimem/release/linux-arm64/archive/aimem-20260904234752.0.0-1.aarch64.rpm) | | APK | amd64 | [aimem\_20260904234752.0.0_x86_64.apk](https://dl.min.io/aistor/aimem/release/linux-amd64/archive/aimem_20260904234752.0.0_x86_64.apk) | | APK | arm64 | [aimem\_20260904234752.0.0_aarch64.apk](https://dl.min.io/aistor/aimem/release/linux-arm64/archive/aimem_20260904234752.0.0_aarch64.apk) | The FUSE path is pure Rust and links no `libfuse`, so the packages depend only on libc (`libc-bin` / `glibc-common`). ### Container Image ```bash # This release, pinned: docker pull quay.io/minio/aistor/aimem:RELEASE.2026-09-04T23-47-52Z # The rolling stable tag — it moves to the next release when one ships: docker pull quay.io/minio/aistor/aimem:latest ``` For verification, pin `RELEASE.2026-09-04T23-47-52Z` or a `@sha256:` digest; never `latest`. The image carries the `aimem` binary. Mounting from a container needs `/dev/fuse` and `CAP_SYS_ADMIN` (or `--privileged`). ### Verification Each binary is signed with both minisign (preferred) and GPG; sha256sums are published alongside. ```bash BASE=https://dl.min.io/aistor/aimem/release/linux-amd64/archive curl -fsSLO $BASE/aimem.RELEASE.2026-09-04T23-47-52Z curl -fsSLO $BASE/aimem.RELEASE.2026-09-04T23-47-52Z.minisig curl -fsSLO $BASE/aimem.RELEASE.2026-09-04T23-47-52Z.sha256sum # minisign minisign -Vm aimem.RELEASE.2026-09-04T23-47-52Z \ -P RWTx5Zr1tiHQLwG9keckT0c45M3AGeHD6IvimQHpyRywVWGbP1aVSGav # sha256 — the checksum file names the versioned binary, so verify under that # name (`sha256sum -c` fails against a file saved as plain `aimem`) sha256sum -c aimem.RELEASE.2026-09-04T23-47-52Z.sha256sum ``` (The minisign public key above is the MinIO release-signing key, shared across the AIStor product line.) --- ## Changes since RELEASE.2026-08-20T22-12-20Z ### Bug Fixes - **`Resource busy` when a file was created and then reopened for writing.** Creating a file with `O_RDWR|O_CREAT`, holding that descriptor, and reopening the same path to write through a second one failed with `Resource busy (os error 16)`. POSIX permits the pattern and `uv` uses it for every file it installs, so `uv sync` could not build a virtualenv on a mount and no Python project could be installed onto one. An `O_RDWR` create now opens for reading and becomes the writer on its first write, so the descriptor that actually writes is the one that gets the file. Two concurrent `O_WRONLY` writers still serialize, as before. Verified end to end with the virtualenv on the mount: `uv sync`, `uv run`, `uv add`, and `npm install` all succeed. - **Writes were silently lost when an existing file was rewritten in place.** An `O_RDWR` open of an existing object could be given the kernel's FUSE passthrough fast path, backed by that file's `--local` cache entry. The kernel then routed the open's writes into the cache entry, where the mount never saw them — nothing was uploaded, and the cache entry was left the wrong length. (The wrong-length entry was rejected on the next open, so no bad data was ever served; the write was simply gone.) It hit anything that edits a file in place: a Linux kernel build on the mount lost the ORC unwind sections objtool appends to each object, yielding a `vmlinux` with no `.orc_unwind*` and `sorttable` reporting `incomplete ORC unwind tables`. Passthrough is now granted only to an open that cannot write, so **writable opens no longer take the kernel fast path**; read-only opens are unchanged. Passthrough requires `CAP_SYS_ADMIN`, so only mounts holding that capability were affected — which includes the documented container mount. ### Platform / Compatibility - Linux amd64 and arm64. amd64 runs on glibc ≥ 2.34, arm64 on glibc ≥ 2.39. - Mounting needs `/dev/fuse`. FUSE passthrough additionally needs `CAP_SYS_ADMIN`; without it a mount serves ordinary FUSE reads. - A Kubernetes cluster picks up both fixes by moving its CSI node driver image to this tag, which bundles the new `aimem`; the driver itself is unchanged. --- ## Documentation - Hosted docs: ## Support - Security disclosures: security@min.io - Licensed customers and contributors: contact MinIO support.