---
title: "15. Multi-Protocol Access (NFS + S3)"
slug: "15-multi-protocol-access-nfs-s3"
description: "VAST enables seamless multi-protocol access via NFS and S3, simplifying data pipelines and ensuring strong consistency without duplication."
updated: 2026-10-28T19:54:28Z
published: 2026-10-28T19:54:28Z
canonical: "docs.vastdata.com/15-multi-protocol-access-nfs-s3"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vastdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 15. Multi-Protocol Access (NFS + S3)

VAST supports multi-protocol access, allowing the same data to be accessed concurrently via NFS (v3/v4) and S3 through a unified, native namespace. This enables seamless access to a single dataset across both file and object protocols, without requiring data duplication, gateways, or transformation. The VAST Element Store provides a shared namespace where file and object protocols operate on the same underlying data structures, ensuring strong consistency and eliminating the need for synchronization between systems. This significantly simplifies data pipelines by avoiding copies and replication, enabling diverse workloads, such as AI/ML training pipelines, analytics workflows, and agentic AI systems, to access and process the same dataset natively across protocols.

![Protocol & data access layer diagram](https://cdn.us.document360.io/89b91113-5dc6-49db-86ec-57b16dc8ce56/Images/Documentation/image(144).png?sv=2026-02-06&spr=https&st=2026-11-08T09%3A06%3A16Z&se=2026-11-08T10%3A06%3A16Z&sr=c&sp=r&sig=sq5bXxfu6IW5XQxbHneOowDFBugqeOzD6EcQ1exUMT4%3D)

## NFS Access Model

NFS provides file-based access using POSIX semantics, where authentication and authorization are based on user identity and filesystem permissions.

| NFS | NFSv3 | NFSv4 |
| --- | --- | --- |
| Authentication | Client-provided UID/GID (no authentication handshake) | User principals (user@domain), optional Kerberos authentication |
| Authorization | POSIX mode bits (UID/GID-based access control) | POSIX mode bits + NFSv4 ACLs (identity-aware access control) |
| Identity Resolution | Not required; server uses UID/GID values directly | Required; identities resolved via idmapd + LDAP/AD |
| Security Model | Trust-based (client asserts identity) | Identity-based (supports authentication with Kerberos) |

## S3 Access Model

S3 provides object-based access to data using API calls (e.g., GET, PUT, LIST), authenticated via access keys and authorized using a policy-based access control model.

|  | S3 Model |
| --- | --- |
| Authentication | Access Key / Secret Key (request signing) |
| Identity Resolution | S3 user (mapped to access keys) |
| Authorization Model | Policy-based (identity policy + bucket policy + ACLs) |
| Permission Control | Defined via policies and ACLs |
| Permission Granularity | Per-user / per-group / per-resource (bucket/object) |
| Default Permissions | Object owner has full control; others require explicit permission |
| Access Model | API-driven (per request evaluation) |

## VAST Security Flavors (Permission Enforcement Model)

The Security Flavor defines how permissions are enforced for a View - Configured per View via View Policy to determine:

- Which protocol can set permissions
- How access is evaluated
- How new objects get initial permissions

Available VAST Security Flavors:

- NFS: POSIX mode bits
- SMB: NTFS ACLs
- Mixed (Last Wins): Combined ACL model - Last writer determines permissions
- S3 Native: S3 policies

Reference: [Controlling File and Directory Permissions Across Protocols](/docs-5-5/docs/security-flavors)

## Using Security Flavors in Multi-Protocol Environments

When exposing the same data via NFS and S3:

- The Security Flavor defines how access is enforced
- There is one permission authority per View

|  | **NFS Security Flavor (POSIX)** | **S3 Native Security Flavor (S3)** |
| --- | --- | --- |
| **Permission authority** | POSIX (UID/GID + mode bits) | S3 (identity policy, bucket policy, ACLs) |
| **S3 writes object** | Object created with POSIX permissions (view policy defaults or parent inheritance) | Owner gets FULL CONTROL (default S3 ACL) |
| **NFS reads file** | Allowed only if POSIX permissions permit | Allowed only if S3 policy/ACL permits |
| **S3 reads object** | Allowed only if POSIX permissions permit | Allowed only if S3 policy/ACL permits |
| **NFS writes file** | Allowed, permissions set via POSIX (NFS controls) | Allowed, but permissions controlled by S3 |
| **NFS chmod** | ✅ Applied (authoritative) | ❌ Ignored |
| **S3 ACL / policy change** | ❌ Ignored for access enforcement | ✅ Applied |
| **S3 identity/bucket policy** | ❌ Not used for access checks | ✅ Used for access checks |
| **Initial permissions (non-native protocol)** | Must be defined in View Policy or inherited | Automatically assigned (owner full control) |
| **Permission evaluation model** | POSIX evaluation (owner → group → others) | S3 evaluation (policy + ACL, most permissive match) |

## Option 1 – NFS Security Flavor (POSIX Authoritative)

Permissions are defined using POSIX (UID/GID + mode bits)

NFS is authoritative; S3 is a non-native access path

### Configuration

- **View Policy**
  - Security Flavor = NFS
  - Define default POSIX permissions (for non-native access)
- **View**
  - NFS namespace (path)
- **NFS Connectivity**
  - VIP Pool
  - Client access (IP / CIDR)
- **Identity**
  - Local / LDAP / AD (UID/GID mapping)
- **S3 Access**
  - S3 users (access keys) for connectivity only
  - S3 policies/ACLs are not used for enforcement

### Access Flow

- **NFS**
  - UID/GID provided by client
  - Access enforced using POSIX permissions
- **S3**
  - Auth via access key
  - Access enforced using POSIX permissions

## Option 2 – S3 Native Security Flavor (S3 Authoritative)

Permissions are defined using S3 policies (identity, bucket, ACL)

S3 is authoritative; NFS is a non-native access path

### Configuration

- **View Policy**
  - Security Flavor = S3 Bucket
- **View**
  - Exposed as S3 bucket namespace
- **S3 Setup**
  - Enable S3 service (tenant)
  - Create users (access key / secret key)
  - Define permissions via:
    - Identity policies
    - Bucket policies
    - (Optional) ACLs
- **NFS Access**
  - Client access (IP / CIDR) for mount only
  - No permission control via NFS

### Access Flow

- **S3**
  - Auth via access key
  - Access evaluated using S3 policies and ACLs
- **NFS**
  - Access evaluated using the S3 permission model

## Example Workflow – Multi-Protocol Access (NFS + S3)

This workflow demonstrates how to configure and validate multi-protocol access (NFS + S3) using S**3 Native Security Flavor**, where:

- S3 is the authoritative permission model
- Identity policies control access (user/group)
- NFS acts as an access path only
- The same data is accessed via both protocols without duplication

This example validates role-based access control (RBAC) using:

- Full-access user
- Read-only group user

### Step 1 – Create Identity Policy

Identity policies define what actions a user or group is allowed to perform on S3 resources (e.g., read, write, list). User Management → Identity Policies → Create

![Show Policy](https://cdn.us.document360.io/89b91113-5dc6-49db-86ec-57b16dc8ce56/Images/Documentation/image(145).png?sv=2026-02-06&spr=https&st=2026-11-08T09%3A06%3A16Z&se=2026-11-08T10%3A06%3A16Z&sr=c&sp=r&sig=sq5bXxfu6IW5XQxbHneOowDFBugqeOzD6EcQ1exUMT4%3D)

#### Example Policy

In the example below, the identity policy grants full read/write access to the admin user while restricting the group to read-only access (list and read operations only).

```plaintext
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UserFullAccess",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    },
    {
      "Sid": "GroupReadOnly",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": "*"
    }
  ]
}
```

### Step 2 – Create Group

This example uses local groups and user: User Management → Local Groups → Create

![Show Group](https://cdn.us.document360.io/89b91113-5dc6-49db-86ec-57b16dc8ce56/Images/Documentation/image(146).png?sv=2026-02-06&spr=https&st=2026-11-08T09%3A06%3A16Z&se=2026-11-08T10%3A06%3A16Z&sr=c&sp=r&sig=sq5bXxfu6IW5XQxbHneOowDFBugqeOzD6EcQ1exUMT4%3D)

### Step 3 – Create Users

We’re creating 2 different users in the same tenant, but they have different access keys - both tenants are in the same group as well. User Management → Local Users → Create

**Note**: You need to generate the access key after the users are created.

First user: ‘s3-test-user’:

![Show User](https://cdn.us.document360.io/89b91113-5dc6-49db-86ec-57b16dc8ce56/Images/Documentation/image(147).png?sv=2026-02-06&spr=https&st=2026-11-08T09%3A06%3A16Z&se=2026-11-08T10%3A06%3A16Z&sr=c&sp=r&sig=sq5bXxfu6IW5XQxbHneOowDFBugqeOzD6EcQ1exUMT4%3D)

### Step 4 – Create View Policy (S3 Native)

Creating a view policy that uses S3 native security flavor for this example:

Element Store → View Policies → Create

![S3 Policy values](https://cdn.us.document360.io/89b91113-5dc6-49db-86ec-57b16dc8ce56/Images/Documentation/image(148).png?sv=2026-02-06&spr=https&st=2026-11-08T09%3A06%3A16Z&se=2026-11-08T10%3A06%3A16Z&sr=c&sp=r&sig=sq5bXxfu6IW5XQxbHneOowDFBugqeOzD6EcQ1exUMT4%3D)

![S3 Permissions](https://cdn.us.document360.io/89b91113-5dc6-49db-86ec-57b16dc8ce56/Images/Documentation/image(150).png?sv=2026-02-06&spr=https&st=2026-11-08T09%3A06%3A16Z&se=2026-11-08T10%3A06%3A16Z&sr=c&sp=r&sig=sq5bXxfu6IW5XQxbHneOowDFBugqeOzD6EcQ1exUMT4%3D)

Configuration summary:

| Field | Value |
| --- | --- |
| Security Flavor | S3 Native |
| Protocols | NFS + S3 |
| Bucket Listing (Users) | `s3-test-user` |
| Bucket Listing (Groups) | `s3-test-group` |
| Check access for listing | Enabled |
| Allow anonymous access | Optional |

### Step 5 – Create View (Shared NFS + S3 Namespace)

The View defines the shared namespace that is exposed simultaneously as an S3 bucket and as an NFS export, allowing both protocols to access the same underlying data. The bucket owner is the first user ('s3-test-user'), which means that the second user ('s3-test-user2') has read and list access only in this bucket (view).

Element Store → Views → Create

![S3 View configuration](https://cdn.us.document360.io/89b91113-5dc6-49db-86ec-57b16dc8ce56/Images/Documentation/image(151).png?sv=2026-02-06&spr=https&st=2026-11-08T09%3A06%3A16Z&se=2026-11-08T10%3A06%3A16Z&sr=c&sp=r&sig=sq5bXxfu6IW5XQxbHneOowDFBugqeOzD6EcQ1exUMT4%3D)

![S3 View configuration](https://cdn.us.document360.io/89b91113-5dc6-49db-86ec-57b16dc8ce56/Images/Documentation/image(152).png?sv=2026-02-06&spr=https&st=2026-11-08T09%3A06%3A16Z&se=2026-11-08T10%3A06%3A16Z&sr=c&sp=r&sig=sq5bXxfu6IW5XQxbHneOowDFBugqeOzD6EcQ1exUMT4%3D)

Configuration summary:

| Field | Value |
| --- | --- |
| View Policy | `s3-test-policy` |
| Tenant | default |
| Bucket Owner | s3-test-user |
| NFS path | /s3-test |
| S3 bucket | s3://s3-test/ |

## Validation Test

### Step 1 – Validate Write via S3 (User1 – Full Access)

```plaintext
export AWS_ACCESS_KEY_ID=<user1_access_key>
export AWS_SECRET_ACCESS_KEY=<user1_secret_key>
export AWS_DEFAULT_REGION=us-east-1

echo "written by user1" > user1.txt

aws --endpoint-url http://172.200.203.3 \
s3 cp user1.txt s3://s3-test/

aws --endpoint-url http://172.200.203.3 \
s3 cp user1.txt s3://s3-test/test.txt
```

Expected:

✔ User1 can create and overwrite objects

### Step 2 – Validate S3 Access (User1)

```plaintext
aws --endpoint-url http://172.200.203.3 s3 ls s3://s3-test/

aws --endpoint-url http://172.200.203.3 \
s3 cp s3://s3-test/test.txt -
```

Expected:

✔ List

✔ Read

### Step 3 – Validate Read-Only Access (User2 via Group)

```plaintext
export AWS_ACCESS_KEY_ID=<user2_access_key>
export AWS_SECRET_ACCESS_KEY=<user2_secret_key>
export AWS_DEFAULT_REGION=us-east-1

aws --endpoint-url http://172.200.203.3 s3 ls s3://s3-test/

aws --endpoint-url http://172.200.203.3 \
s3 cp s3://s3-test/test.txt -
```

Expected:

✔ List

✔ Read

### Step 4 – Validate Write Restriction (User2)

This step is expected to fail because User2 has read-only access.

```plaintext
echo "test write" > fail.txt

aws --endpoint-url http://172.200.203.3 \
s3 cp fail.txt s3://s3-test/
```

Expected result:

✔ AccessDenied

### Step 5 – Mount via NFS

```plaintext
sudo mount -o proto=tcp,nconnect=32,vers=3,remoteports=dns \
172.200.203.3:/s3-test /mnt/mordi
```

### Step 6 – Validate NFS Access (User1)

```plaintext
sudo -u s3-test-user ls -lh /mnt/mordi
```

### Step 7 – Validate NFS → S3 Consistency

Write via NFS:

```plaintext
sudo -u s3-test-user bash -c 'echo "hello from nfs" > /mnt/mordi/nfs.txt'
```

Read via S3:

```plaintext
export AWS_ACCESS_KEY_ID=<user1_access_key>
export AWS_SECRET_ACCESS_KEY=<user1_secret_key>

aws --endpoint-url http://172.200.203.3 \
s3 cp s3://s3-test/nfs.txt -
```

Expected:

✔ hello from nfs

### Step 8 – Validate S3 → NFS Consistency

Write via S3:

```plaintext
echo "hello from s3" > s3file.txt

aws --endpoint-url http://172.200.203.3 \
s3 cp s3file.txt s3://s3-test/s3file.txt
```

Read via NFS:

```plaintext
sudo -u s3-test-user cat /mnt/mordi/s3file.txt
```

Expected:

✔ hello from s3

### Step 9 – Validate NFS Access (User2)

User2 must exist on Linux with a matching UID/GID.

```plaintext
sudo -u s3-test-user2 ls -lh /mnt/mordi
sudo -u s3-test-user2 cat /mnt/mordi/test.txt
```

Expected:

✔ Read works

### Step 10 – Validate NFS Write Restriction (User2)

```plaintext
sudo -u s3-test-user2 bash -c 'echo "test write" > /mnt/mordi/fail.txt'
```

Expected:

✔ Permission denied