S3 with NFS use case
Access Appliance supports multi-protocol support for NFS with S3. If an NFS share is present (and objects may be present in the exported path), the storage admin can map that path as an S3 bucket (S3 over NFS). In addition, a normal file system path can also be mapped as an S3 bucket. The buckets created by S3 APIs cannot be exported as an NFS share (NFS over S3).
The path has the following characteristics:
Path is the absolute path inside a file system.
The name of the bucket is the name of the directory of the path which should be S3 compliant.
The path can be either NFS exported path or any directory in the normal file system. You cannot use the ObjectAccess file systems (file system having S3 bucket created by S3 APIs).
No other bucket should exist with the same name.
No other bucket should be present either inside or outside the given path. You can verify this using the following command:
objectaccess> bucket show
NFS share should not be present before or after that directory. You can verify using the following command:
NFS> share show
You can configure the cluster with any authentication server like AD/LDAP. Then, all the users present in the authentication server can be used as S3 users.
The S3 user should be authorized to access the S3 bucket (access key and secret key should be present for that user). You can verify using the following command:
objectaccess> account user show
See Configuring the Object Store server.
You can map the path to a bucket. The path can be either a directory inside a file system or an NFS-exported path. If the specified path is not present, then the map command creates the directory and sets the default S3 bucket permissions.
You can map the path to the S3 bucket for the user using the following command:
objectaccess> map <path> <user>
The storage admin can verify the bucket creation using the following command:
objectaccess> bucket show
The storage admin can use the NFS share at the same time when the S3 user uses the bucket. Existing objects inside the bucket retain the permissions set by the owner of those objects.
In multi-protocol case, an S3 user can delete the bucket without deleting all the objects. Deleting the bucket is equivalent to unmapping or unreferencing the bucket.
The following limitations apply for multi-protocol support:
An S3 user cannot access a bucket if the bucket ownership or permissions from the NFS client is changed.
Permissions that are set or modified from protocols like NFS are not honored by S3 and vice versa.
Object ETag is inaccurate whenever object is created or modified from the NFS client. An incorrect ETag is corrected when a GET or HEAD request is performed on the object.
Accessing the same object from different protocol in exclusive mode is not supported.