Sharing and mounting a file share from another account
As a storage administrator that manages multiple accounts, you can share an NFS file system across accounts, so the data that your applications depend on is available across the different systems within the company. You can also share your File Storage for VPC with the IBM watsonx service.
Cross-account service-to-service authorization is used to establish trust between share owner and accessor accounts. Also, the appropriate IAM platform and services roles must be assigned to the users so they can perform their tasks. To create an accessor share within the same account as the origin share, the user must have Share Broker and Editor roles. To create an accessor share within the a different account from the origin share, the user must have Share Remote Account Accessor and Editor roles. For more information, see IAM Roles and actions.
After the authorization is set in place and roles are assigned, you can create an accessor share that is bound to the origin share. The accessor share inherits the profile, size, encryption type both at rest and in-transit from the origin share. The origin share's account can see the IDs of the accounts who can mount the shared NFS share.
As the accessor, you can't edit the properties of the origin share, and you can't delete the origin share. The accessors can mount the share by creating an accessor share and a mount target to the accessor share. Then, you can access and use the data of the origin share in your own VPCs.
Transit Encryption Policy
The share owner has the right to enforce the use of encryption in transit when the accessor accesses the file share data. The share owner can set the allowed transit encryption modes to allow either user_managed
or none
,
or both. When the allowed transit encryption modes
of the origin share is set to user_managed
, the share accessor accounts must create all their mount targets with user_managed
transit encryption. If
the accessor account has more than one mount targets, these mount targets must have the same type of encryption in transit.
File shares that were created before the release of this feature (18 June 2024) have an allowed transit encryption type that is based on their existing mount targets. After this date, you must specify the allowed transit encryption type when you create file shares. All mount targets that are created for one file share must have the same transit encryption type.
Creating an accessor share in the UI
In the IBM Cloud console, you can create an accessor share with or without a mount target. However, you need to create a mount target when you want to mount the share on a virtual server instance.
Creating an accessor share in the UI
-
In the IBM Cloud console, click the Navigation menu icon
> VPC Infrastructure
> Storage > File Shares. A list of file shares displays.
-
On the File shares for VPC page, click Create > Create accessor share.
-
Enter the following information.
Table 1. Values for creating a file share Field Value Accessor share name Specify a meaningful name for your accessor share. The file share name can be up to 63 lowercase alpha-numeric characters and include the hyphen (-), and must begin with a lowercase letter. You can later edit the name if you want. Remote share CRN Enter the CRN of the origin file share. -
You return to the File Storage for VPC page, where a message indicates that the file share is provisioning. When the transaction completes, the share status changes to Active.
Creating an accessor share from the CLI
Creating a mount target for an accessor share from the CLI
To create a mount target for the file share, run the share-mount-target-create
command. Before you begin, gather some necessary information.
When you create a mount target, you must specify the file share that it is for. You can use the file share's name or ID. You must specify the VPC, too, either with its ID or name. The VPC must be unique to each mount target. You must also specify the security access group that's going to be used to manage access to the share. The security groups that you associate with a mount target must allow inbound access for the TCP protocol on the NFS port from all virtual server instances on which you want to mount the file share.
Lastly, you must specify values for the options that are needed to create a virtual network interface for the mount target. Use the appropriate CLI commands to list the available subnets, reserved IP addresses in a subnet, security groups to get the information that you need.
The following example creates a mount target with a virtual network interface for a file share that has security group access mode.
$ ibmcloud is share-mount-target-create my-accessor-share --subnet my-subnet --name my-cli-share-mount-target-1 --vni-name my-share-vni-1 --vni-sgs my-sg --resource-group-name Default --vpc my-vpc
Mounting target for share r006-b696742a-92ee-4f6a-bfd7-921d6ddf8fa6 under account Test Account as user test.user@ibm.com...
ID r006-dd497561-c7c9-4dfb-af0a-c84eeee78b61
Name my-cli-share-mount-target-1
VPC ID Name
r006-6e8fb140-5668-45b8-b98a-d5cb0e0bf39b my-vpc
Access control mode security_group
Resource type share_mount_target
Virtual network interface ID Name
r006-13c070d8-d038-49c6-95f5-e8503c5595e3 my-share-vni-1
Lifecycle state pending
Mount path -
Transit Encryption none
For more information about the command options, see ibmcloud is share-mount-target-create
.
Creating an accessor share with the API
You can create file shares and mount targets by directly calling the REST APIs.
Before you begin
Set up your API environment. Define variables for the IAM token, API endpoint, and API version. For instructions, see Setting up your API and CLI environment.
Creating a mount target for a file share with the API
If the share's access control mode is security_group
, then the mount target must be created with a virtual network interface. When the share's allowed transit encryption mode is user-managed
,
the mount target's transit_encryption
value must be user-managed
, too.
Make a POST /shares/{share_id}/mount_targets
request and specify a subnet and security group for the mount target network interface. The security groups that you associate with a mount target must allow inbound access for the
TCP protocol on the NFS port from all virtual server instances on which you want to mount the file share.
This example adds a mount target to an existing accessor share, which is identified by ID, and provides a subnet and security group to create the network interface.
curl -X POST "$vpc_api_endpoint/v1/shares/f1ab81ef-dd30-459a-85e0-9094164978b1/mount_targets/?version=2023-07=18&generation=2"\
-d '{
"virtual_network_interface": {
"subnet": {"id": "1a0b3d75-8a62-4c78-9263-f9bcd25a8759"},
"security_groups": [{"id": "b2599112-7027-480e-ad1b-fd917d2fcb84"}]
},
"transit_encryption": "user_managed"
}'
Creating a file share and mount target with Terraform
To use Terraform, download the Terraform CLI and configure the IBM Cloud® Provider plug-in. For more information, see Getting started with Terraform.
VPC infrastructure services use a specific regional endpoint, which targets to us-south
by default. If your VPC is created in another region, make sure to target the appropriate region in the provider block in the provider.tf
file.
See the following example of targeting a region other than the default us-south
.
provider "ibm" {
region = "eu-de"
}
Next steps
Mount your file shares. Mounting is a process by which a server's operating system makes files and directories on the storage device available for users to access through the server's file system. For more information, see the following topics: