Yes. ZEDEDA/EVE-OS supports attaching a single volume instance to multiple application instances via the multiattach flag combined with the MULTIREAD_SINGLEWRITE access mode. Sharing data between edge apps on the same node is one of the documented primary use cases of the storage feature.

This is a supported, real-world pattern: a single block-storage volume (optionally backed by a shared content tree) attached to multiple app instances on one node with multiattach=True.

The accessmode field accepts these enum values:

To share, use MULTIREAD_SINGLEWRITE and set multiattach = true.

• Same node only. A persistent volume instance belongs to a specific edge node. To share it, every app instance attaching it must run on that same edge node. To have it on another node you must create a separate volume instance there.
• One writer, many readers. MULTIREAD_SINGLEWRITE means the platform lets multiple apps attach, but it does not arbitrate concurrent writers. Two apps mounting the same block device read-write and both writing will corrupt the filesystem (ext4/xfs are not cluster-aware).
• Safe pattern: one app owns writes; the others mount read-only (readonly = true on the drive). If you genuinely need concurrent read-write from multiple apps, do not use block-level multiattach — instead have one app export the data over a network share (NFS / SMB / MinIO) that the others mount.

At any given time only one app may mount the volume read-write; every other app must mount it read-only. A few points that are easy to get wrong:

• It is not enforced automatically. EVE will not stop you from setting readonly = false on two apps. If you do, both mount /data read-write, both can write, and the filesystem will corrupt. Safety comes entirely from you marking all-but-one drive as readonly = true.
• The writer role can be changed, but not doubled. To hand off the writer role, flip the flags (old writer → readonly = true, new writer → readonly = false) and re-apply, so the volume is only ever mounted read-write by one app at a time. This is an operational hand-off, not concurrent shared writing.
• Readers do not see live updates. A read-only block mount does not track the writer's new files in real time — the reader's filesystem cache is unaware of changes the writer makes. “One writes, others read” works best when readers mount after the data is written, or remount to pick up changes. It is not a live shared filesystem.

Rule of thumb:

• One app produces data, the other(s) only consume it → multiattach with writer/reader flags is fine.
• Multiple apps need live concurrent read-write on shared files → block-level multiattach is the wrong mechanism regardless of the flags. Run an NFS / SMB server app on the volume and have the others mount it over a local network instance for coherent, concurrent read-write.

The zedcloud_volume_instance resource exposes both accessmode and multiattach, so this is done entirely in Terraform.

resource "zedcloud_volume_instance" "shared_persist" {
  device_id   = zedcloud_edgenode.my_edgenode.id
  accessmode  = "VOLUME_INSTANCE_ACCESS_MODE_MULTIREAD_SINGLEWRITE"
  multiattach = true
  cleartext   = false
  label       = "shared-persist"
  name        = "shared-persist"
  size_bytes  = 1073741824
  title       = "shared-persist"
  type        = "VOLUME_INSTANCE_TYPE_BLOCKSTORAGE"
  lifecycle {
    ignore_changes = [device_id]
  }
}

  drives {
    imagename   = ""
    volumelabel = zedcloud_volume_instance.shared_persist.label
    mountpath   = "/data"
    cleartext   = false
    ignorepurge = true
    maxsize     = 1073741824
    preserve    = true
    target      = "Disk"
    drvtype     = "HDD"
    readonly    = false   ### writer
  }

  drives {
    imagename   = ""
    volumelabel = zedcloud_volume_instance.shared_persist.label
    mountpath   = "/data"
    cleartext   = false
    ignorepurge = true
    maxsize     = 1073741824
    preserve    = true
    target      = "Disk"
    drvtype     = "HDD"
    readonly    = true    ### reader
  }

Referencing the same volume from two app instances while the volume is still defined as plain VOLUME_INSTANCE_ACCESS_MODE_READWRITE with no multiattach is not a valid shared config — it either fails to attach to the second app or produces two uncoordinated read-write mounts. Always set multiattach = true + MULTIREAD_SINGLEWRITE, and keep only one writer.

• Sharing a persistent volume across apps is supported — multiattach = true + MULTIREAD_SINGLEWRITE.
• Same edge node for all attaching apps.
• One writer, others read-only; for concurrent multi-writer, use a network share instead.
• Fully configurable in the zedcloud Terraform provider (accessmode, multiattach, per-drive readonly).