Skip to main content
You can use the archil CLI to mount an Archil disk locally to an already running Linux server — such as an Amazon EC2 instance, a microVM sandbox, or a VPS. Archil is compatible out-of-the-box with all programs that run on Linux, such as git, SQLite, or ffmpeg. For more details, see Application compatibility.
This article is for servers which are running their own Linux kernel. If you’re trying to mount Archil into a container such as Docker, Podman, or a container platform (such as Amazon ECS) see Mount in a container.
1

Install the client

The archil client provides support for mounting Archil disks on Linux. First, install it on your server:
2

Authorize your server

Each server that connects to the Archil disk needs to be authorized. You can managed which servers are authorized in the Archil console, by navigating to the disk that you want to use, then selecting Connections in the left-bar, and clicking Add User to authorize a new server.Select Disk Token, and save the token somewhere you can retrieve it, you will not be able to see it again.
Archil disks also support IAM authentication for users mounting from within AWS. For more details on how disks authenticate users, see Disk users.
3

Mount the disk

First, create the directory that you intend to use to mount Archil:
Using the token that you just saved from the console, you can now mount the disk with archil mount.
You can now use any Linux program against your Archil disk by navigating to /mnt/archil, and running commands.

​
Disk ownership

By default, new Archil disks are owned by the root user (Linux uid:0). When you mount your disk to a folder such as /mnt/archil, that folder will become owned by the root user. When not running as the root user, you will see EACCES: Permission denied for file operations. You can change the owner of the root directory with the command: sudo chown $(id -u):$(id -g)" /mnt/archil The ownership change will be persisted

​
Mounting on multiple hosts

By default, your disk is mounted in exclusive-ownership mode. If you would like to mount the disk on multiple servers, instead call archil mount --shared and familiarize yourself with the Shared disk semantics. When you mount an Archil disk with --shared, you need to manually manage write-ownership of different files and folders on the Archil disk. This requires calling archil checkout <file> before writing and archil checkin <file> after writing, otherwise these operations will fail with EROFS: Read-only file system.

​
Ensuring that data is persisted on shutdown

Like all local file systems, Archil automatically stages recently written data in-memory until an explicit fsync or a periodic background flush job writes it to durable storage. This means that recently-written data may not be persisted if a machine is unexpectedly powered off. Archil sandboxes automatically manage this persistence on shutdown. On other sandbox providers, make sure that you explicitly call archil unmount before powering off the sandbox. We recommend always using archil unmount instead of the built-in Linux umount command, which does not automatically flush data to Archil’s servers.

​
Mount automatically on startup

If your service automatically launches new instances, such as in a load-based auto scaling group, you’ll want to ensure that new servers automatically mount Archil at startup. In addition to service startup scripts, you can achieve this by adding Archil to the server’s /etc/fstab with a line like the following:
Parameters:
  • <disk-name>: An owner-qualified disk name (organization/disk-name or employee@email.com/disk-name) or disk ID (dsk-0123456789abcdef).
  • <mountpoint>: Local directory where the disk should be mounted (e.g., /mnt/archil).
  • archil: Filesystem type for Archil disks.
  • _netdev: Tells systemd this is a network filesystem that needs network connectivity before mount.
  • region=<region>: The region your disk is in (e.g., aws-us-east-1).
Example: