Skip to main content
Mounting an Archil disk in an E2B, Daytona, Modal, or Vercel sandbox works much like it does on any Linux server. The main difference is that the platform can stop the machine while the disk is still mounted, for example when a sandbox reaches its timeout. This page covers what happens then, how to recover, and a few platform-specific details.

A sandbox stopped with the disk mounted

The archil client buffers recent writes in memory and sends them to the disk in the background. A plain (exclusive) mount also holds a lock on the disk, called a delegation, so that no other client writes to it at the same time. archil unmount sends every buffered write and then releases the lock. If the sandbox is killed, stopped, or times out before it unmounts:
  • Recent writes can be lost. Writes the client hadn’t sent yet never reach the disk.
  • The disk stays locked. The lock still belongs to the client in the old sandbox, so the next exclusive mount fails with:
To avoid both, unmount in a finally block or a shell trap before you stop the sandbox (on Daytona, run archil sync and archil checkin instead, as described below), and give the sandbox a timeout longer than the work it does.

Release a stale lock

Once the old client stops responding, Archil marks its delegations as orphaned, usually within a minute. Revoke them with the SDK from your machine:
The next mount then succeeds. Revoking only orphaned delegations can’t interrupt a client that’s still connected. archil mount --force also takes the disk back, but it revokes every other client’s delegations, including those of sandboxes that are still running. See Forcing ownership.

The installer fails with libfuse2 ... not installable

The default images on E2B, Daytona, and Vercel Sandbox ship without package lists, so the installer can’t fetch its libfuse2 dependency:
Run apt-get update (with sudo where the default user isn’t root) before curl -fsSL https://archil.com/install | sh.

Platform notes

E2B

  • Run archil mount and archil unmount with user: "root". As the default user, the mount fails with The mount command requires root privileges.
  • E2B kills a sandbox when it reaches its timeout, whether or not the disk is unmounted. Set timeoutMs (timeout in Python) longer than the session.

Daytona

  • archil unmount fails inside a Daytona sandbox with Unable to unmount disk: GenericFailure("No such file or directory (os error 2)"), because the container runtime doesn’t let the client detach a FUSE mount (umount and fusermount3 -u fail too). Run sudo archil sync <path> && sudo archil checkin <path> instead: sync sends every buffered write, and checkin releases the lock. Then delete the sandbox.
  • Daytona stops a sandbox after 15 minutes without activity by default. If a session can sit idle longer, raise autoStopInterval when you create the sandbox.
  • Pass the mount token as a regular environment variable. With a Daytona secret, the sandbox sees a placeholder instead of the token, and the mount fails with Authentication failed.
  • archil mount only works in VM Sandboxes (runtime="vm"). In Modal Functions and in Sandboxes on the default gVisor runtime, it fails with Operation not permitted (os error 1). From those, read and write the disk with the Python SDK instead.
  • Modal terminates a Sandbox at its timeout without running a shell trap. Set timeout longer than the work.

Vercel Sandbox

  • When a sandbox stops or reaches its timeout, the client usually sends its writes and releases the disk on the way out. Stopping it in the middle of heavy writes, such as an npm install, can still leave the disk locked. Unmount before stop(), and call sandbox.extendTimeout() for long jobs.
  • Create the sandbox in the Vercel region next to the disk’s region (iad1 for aws-us-east-1, pdx1 for aws-us-west-2, dub1 for aws-eu-west-1). In a distant region, every read that misses the cache crosses the country.