--- title: "Global Namespace Overview" slug: "global-namespace-overview" tags: ["5.4"] updated: 2026-10-28T01:53:46Z published: 2026-10-28T01:53:46Z canonical: "docs.vastdata.com/global-namespace-overview" --- > ## 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. # Global Namespace Overview The VAST global namespace enables you to make paths on clusters available to clients of multiple other clusters without the clients having access to the original cluster on which the path resides. These paths are known as global folders. A global folder is configured in VMS by creating a *protected path* and setting its mode to *global access*. Destination paths (also known as *satellites*) can be configured on multiple peers, one per cluster. The data in the global folder is not synced to the satellites but it is immediately accessible for read and write requests to the satellites as soon as the global access path is created. Data that clients request to read from a satellite is requested from the origin and cached by the satellite. When a satellite peer receives a read request for data that is not cached, the satellite peer reads the data from the origin and prefetches other relevant data and metadata from the origin. If data is accessed multiple times in a given time-frame, the destination peer requests or renews a lease on the data. For the duration of the lease, the destination peer answers read requests on the leased data without refreshing the data from the source. If the lease expires or if the content has changed at the source, the destination peer invalidates the cache. The next time the same data is requested from the destination peer, the destination peer fetches the data again from the source. The lease expiration time is configured per *global access* source path. You can prefetch data in specific folders in a path on the destination peers from the source peer. This data is copied to the cache on the destination cluster. The operation is initiated on the destination peer. Clients can also write data to the path. The write requests are sent to the origin cluster. The source path must be a path that exists prior to configuring the global access. Multiple satellites are supported per source path. The destination path (satellite) is a new path created automatically as part of the global access configuration. ## Limitations - Write Once Read Many (WORM) is not supported on global folders - Event Notification is not supported on global folders - Indestructible Object Mode is not supported on global folders - S3 bucket logging is supported only if both the source bucket and the destination bucket are in the same global folder. - Configuring a global folder with source and destination paths shared with asynchronous replication is supported with limitations. For details, see [Configuring Async Replication and Global Access on Shared Paths](/docs-5-4/docs/en/configuring-async-replication-and-global-access-on-shared-paths). ## Supported Protocols Global folders can be accessed by NFSv3, SMB and S3 protocols, provided a view is created on the path with the relevant protocols enabled. > [!NOTE] > Note > > It is recommended to upgrade clusters to VAST Cluster 5.4.6 if you are enabling SMB client access to global folders. This is due to some cases that can arise with earlier versions where SMB access to the folder can be blocked. To clarify whether this applies to your use case, please contact Customer Success. ### Restrictions on Protocol Combinations S3 access to global folders requires the use of the S3 Native security flavor. NFS access to global folders requires the use of the NFS security flavor. Therefore, the combination of S3 and NFS cannot be enabled on a view of the satellite path. ### NFSv3 and SMB Client Access to Global Folders Clients with an NFSv3 or SMB mount to a path on a destination cluster have visibility and access to paths under this mount path that are configured for global access. For example, consider a cluster (the source) with a protected path `/a/b`, which is configured for global access to a destination cluster as path `/x/y`. On the destination cluster, if there is a view on `/x` that is enabled for NFSv3 and/or SMB access, an NFSv3 or SMB client that mounts `/x` can access `/x/y`. (If the view on the path `/x` is also enabled for NFSv4 access, NFSv4 clients will not see the `/x/y` path. ### S3 Client Access to Global Folders - [Creating S3 Buckets on the Satellite](/docs-5-4/docs/en/global-namespace-overview#creating-s3-buckets-on-the-satellite) - [Replication of S3 Access Keys and Identity Policies](/docs-5-4/docs/en/global-namespace-overview#replication-of-s3-access-keys-and-identity-policies) #### Creating S3 Buckets on the Satellite In order for S3 clients to access the satellite folder, an S3 bucket is needed on the satellite path. You can accomplish this by enabling automatic bucket replication which replicates buckets on the satellite. Alternatively, and only if automatic bucket replication is not enabled, you can manually create a bucket on the satellite path to the global folder. *Bucket replication* is a setting that can be enabled on each cluster (see [Configuring Global Access](/docs-5-4/docs/configuring-global-access)). Provided bucket replication is enabled on both clusters, and a bucket is configured on the source path with the *S3 default* view policy, and the destination tenant on the satellite cluster has the S3 default view policy, the bucket is replicated automatically to the satellite. Configuring Global Access If there is already a bucket on the satellite path with the same name as the origin bucket before you enable bucket replication, the attributes of the origin bucket will be replicated to that bucket. If there is already a bucket on the satellite path with a different name, bucket replication will fail and raise an alert. Bucket replication applies the following bucket attributes from the origin bucket to the satellite bucket: - Whether *Versioning* is enabled or not - Whether *Object Lock* is enabled or not - Object ownership rule - Whether *Allow anonymous access* is enabled or not - Whether the bucket is a database (has *Database* in the list of enabled protocols on the view) - The bucket policy - Whether *Bucket logging* is enabled or not - Bucket owner Buckets that are created by the bucket replication feature are created as bucket-enabled views with the S3 default view policy of the remote tenant. If bucket replication is not enabled on the origin cluster, a bucket must be created manually on the satellite path to enable access. The bucket configuration must mirror the configuration of the source bucket. #### Replication of S3 Access Keys and Identity Policies As part of the configuration of a global access path, a replication peer is created between the origin and the satellite. When a replication peer is configured between two clusters, S3 access key pairs and identity policies are replicated between the clusters as follows: - Access key pairs and identity policies associated with any users on external authorization providers that are configured on each peer are replicated from each peer to the other. Access keys and identity policies are not replicated for users on the cluster's VAST providers. - Each cluster stores access key pairs and identity policies as either local or remote. Access keys and identity policies that are received by replication from remote peers are stored as remote. They cannot be modified or deleted on the remote peer to which they are replicated, although they can be enabled and disabled there. On their source, they can be modified or deleted and those changes are replicated. Remote identity policies are disabled by default. ## Global Access and Async Replication Coexistence You can activate Global Access and Async Replication on the same protected path to provide unified data access and disaster recovery. > [!WARNING] > Warning > > The reverse configuration—creating a destination cluster first and then enabling Async Replication—is not supported. To transition an existing global access path to a replication stream, you must first disable the global access capability on the destination path. ### Coexistence Requirements When deploying or modifying a coexistence path, the cluster enforces the following structural requirements and configuration constraints: - Directional Mapping: The async replication source path must always serve as the global access source. The async replication target path serves as the global access destination path. - Initial Setup Restrictions (replication sequence): You cannot add an async replication relationship directly to a standalone global access path. To establish replication on an existing global access directory, you must first remove the global access configuration from the path, configure the replication relationship, and then enable coexistence. - Modifying Active Streams (replication-only transition): For an active coexistence stream (Async Replication + Global Access), you can dynamically modify the path's capabilities after creation. To convert a coexistence stream into a standard, replication-only stream, you can toggle the Global Access capability off directly within the stream's modification settings. - Management Authority Limits: Under normal operating conditions, modifications to the coexistence capabilities (toggling it on or off) can only be executed from the VMS of the group's source cluster. ### Pausing Global Access on Coexist Destination Clusters During Disconnections While the source cluster usually dictates all capability states, a critical management exception is granted if a cross-cluster network partition occurs or both clusters are connected. If an active coexistence stream member becomes entirely disconnected from the source, you can use the destination cluster's local management interface to manually pause or disable the global access capability. This allows you to access localized snapshot states on the destination cluster and frees up system resources until cross-cluster connectivity is restored. ### Destination-Initiated Capability Removal Operations To resolve situations where a disconnected destination cluster needs to immediately drop back to serving standard replication snapshot data, the destination cluster can independently force the removal of its Global Access state. ​When you trigger this action from the destination cluster, the engine utilizes a local staging mask to temporarily override the authoritative cluster state. This ensures that local data-path operations immediately ignore Global Access restrictions, refresh bucket states, and allow standalone read access to your replication snapshots while the background process handles authoritative coordination with the source cluster once the network path recovers.