Este contenido no está disponible en el idioma seleccionado.

Chapter 6. Performing operations with the Shared File Systems service (manila)


You can create and manage shares in the Shared File Systems service (manila) to provide remote, shareable POSIX-compliant file systems for your cloud instances. Shares allow multiple instances to access the same file system simultaneously. You can perform operations such as creating shares from different protocols (NFS, CIFS, CephFS), managing snapshots, controlling access permissions, and mounting shares on compute instances.

Note

To execute openstack client commands on the cloud, you must specify the name of the cloud detailed in your clouds.yaml file. You can specify the name of the cloud by using one of the following methods:

  • Use the --os-cloud option with each command:
$ openstack flavor list --os-cloud <cloud_name>

Use this option if you access more than one cloud.

  • Create an environment variable for the cloud name in your bashrc file:
`export OS_CLOUD=<cloud_name>`

6.1. Prerequisites

  • The administrator has created a project for you, and they have provided you with a clouds.yaml file for you to access the cloud.
  • You have installed the python-openstackclient package.

6.2. Listing Shared File Systems service share types

You must specify a share type when you create a share in the Shared File Systems service (manila), and you can only create shares that match the available share types. Share types define the service characteristics and back-end configurations that the scheduler uses to make placement decisions and that drivers use to control how shares are created. Listing available share types helps you understand which options are available for your deployment.

Procedure

  • List the available share types:

    $ openstack share type list

    The command output lists the name and ID of the available share types.

6.3. Creating NFS, CephFS, or CIFS shares

You can create CephFS-NFS, native CephFS, or CIFS shares to read and write data.

When you create a share, you must specify the share protocol and the size of the share in gigabytes. You can also include the share-type, share-network and name command options:

$ openstack share create [--share-type <share_type>] \
        [--share-network <share_network>]  \
        [--name <share_name>] <share_protocol> <GB>

In the command example, replace the following values:

Expand
ValueDescriptionRequired or optional

<share_type>

Applies settings associated with the specified share type

Optional. If you do not specify a share type, the default share type is used.

<share_network>

The name of the share network

  • Required if the share type has driver_handles_share_servers set to true.
  • Unsupported if the share type has driver_handles_share_servers set to false.
  • Unsupported for CephFS-NFS and native CephFS. These protocols do not support share types that have driver_handles_share_servers set to true.

<share_name>

The name of the share

Optional. Shares are not required to have a name, and the name does not need to be unique.

<share_protocol>

The share protocol you want to use

  • For CephFS-NFS, replace <share_protocol> with nfs.
  • For native CephFS, replace <share_protocol> with cephfs.
  • For other storage back ends that support NFS or CIFS protocols, for example, NetApp or Dell EMC storage back ends, replace <share_protocol> with nfs or cifs.

<GB>

The size of the share in gigabytes

Required.

6.3.1. Creating NFS or CIFS shares with DHSS=true

When the share type extra specification, driver_handles_share_servers is set to true, you can add your own security services to a share network to create and export NFS or CIFS shares. The native CephFS protocol does not support share networks.

To add a security service, you must create a share network first. If you are creating CIFS shares, you must also create a security service resource to represent your Active Directory server. You then associate the security service to the share network.

If you are creating NFS shares, you do not require a security service unless you want to use Kerberos or LDAP authorization on your shares.

Procedure

  1. Create a share network:

    $ openstack share network create --name <network_name> \
        --neutron-net-id <25d1e65c-d961-4f22-9476-1190f55f118f> \
        --neutron-subnet-id <8ba20dce-0ca5-4efd-bf1c-608d6bceffe1>
    • Replace <network_name> with the share network name that you want to use for your NFS or CIFS shares.
    • Replace the neutron-net-id and neutron-subnet-id with the correct values for your share network.
  2. Create a security service resource to represent your Active Directory server:

    $ openstack share security service create <active_directory> \
              --dns-ip <192.02.12.10> \
              --domain <domain_name.com> \
              --user <administrator> \
              --password <password> \
              --name <AD_service>
    • Replace the values in angle brackets <> with the correct details for your security service resource.
  3. Associate the security service resource to the share network:

    $ openstack share network set --new-security-service \
      <AD_service> <network_name>
  4. Create an NFS or CIFS share:

    • 10 GB NFS example:

      $ openstack share create --name <nfs_share> --share-type <netapp> \
          --share-network <nfs_network> nfs 10
    • 20 GB CIFS example:

      $ openstack share create --name <cifs_share> --share-type dhss_true \
          --share-network <cifs_network> cifs 20
      • Replace the values in angle brackets <> with the correct details for your NFS or CIFS share.

6.3.2. Creating NFS, CephFS, or CIFS shares with DHSS=false

When the share type extra specification, driver_handles_share_servers, is set to false, you cannot use custom security services because security services have been configured directly on the storage system. Because CIFS shares require an Active Directory server along with the storage system to manage access control, your administrator must pre-create an Active Directory server and associate it with the storage system to use CIFS shares.

When DHSS=false, you can create shares without using the share-network command option because the shared storage network is pre-configured.

Procedure

  • Create an NFS, native CephFS, or CIFS share when DHSS=false. These examples specify a name, but they do not specify the share-type or share-network. They use the default share type and the configured shared storage network:

    • Create a 10 GB NFS share named share-01.

      $ openstack share create --name share-01 nfs 10
    • Create a 15 GB native CephFS share named share-02:

      $ openstack share create --name share-02 cephfs 15
    • Create a 20 GB CIFS share named share-03:

      $ openstack share create --name share-03 cifs 20

6.4. Listing shares and exporting information

To verify that you have successfully created NFS, CephFS, or CIFS shares in the Shared File Systems service (manila), you can list the shares and view their export locations and parameters.

Procedure

  1. List the shares:

    $ openstack share list
  2. View the export locations of the share:

    $ openstack share export location list <share_id>
    • Replace <share_id> with either the share name or the share ID.
  3. View the parameters for the share:

    $ openstack share export location show <share_id> <export_location_id>

6.5. Creating snapshots of shared file system data

You can create snapshots of shares to preserve a read-only, point-in-time copy of data stored on a shared file system. Snapshots help you recover data that was accidentally deleted or corrupted, providing a safety net for your file system data. Snapshots are more space-efficient than backups and do not impact the performance of the Shared File Systems service (manila).

Prerequisites

  • The snapshot_support parameter must equal true on the parent share. You can run the following command to verify:

    $ openstack share show | grep snapshot_support

Procedure

  1. Create a snapshot of a share:

    $ openstack share snapshot create [--name <snapshot_name>] <share>
    • Replace <share> with the name or ID of the share for which you want to create a snapshot.
    • Optional: Replace <snapshot_name> with the name of the snapshot.
  2. Confirm that you created the snapshot:

    $ openstack share snapshot list --share <share>

    Replace <share> with the ID of the share from which you created the snapshot.

6.5.1. Creating Shared File Systems shares from snapshots

You can create a share from a snapshot. If the parent share that the snapshot was created from has a share type of driver_handles_share_servers set to true, the new share is created on the same share network as the parent, and you cannot change this share network for the new share.

Prerequisites

  • The create_share_from_snapshot_support share attribute is set to true.
  • The status attribute of the snapshot is set to available.

Procedure

  1. Retrieve the ID of the share snapshot that contains the data that you require for your new share:

    $ openstack share snapshot list
  2. A share created from a snapshot can be larger, but not smaller, than the snapshot. Retrieve the size of the snapshot:

    $ openstack share snapshot show <snapshot_id>
    • Replace <snapshot_id> with the ID of the snapshot you want to use to create a share.
  3. Create a share from a snapshot:

    $ openstack share create <share_protocol> <size> \
       --snapshot-id <snapshot_id> \
       --name <name>
    • Replace <share_protocol> with the protocol, such as NFS.
    • Replace <size> with the size of the share to be created, in GiB.
    • Replace <name> with the name of the new share.
  4. List the shares to confirm that the share was created successfully:

    $ openstack share list
  5. View the properties of the new share:

    $ openstack share show <name>

Verification

After you create a snapshot, confirm that the snapshot is available.

  • List the snapshots to confirm that they are available:

    $ openstack share snapshot list

6.5.2. Deleting a Shared File Systems share snapshot

When you create snapshots of a share, you cannot delete the share until you delete all of the snapshots created from that share.

Procedure

  1. Identify the snapshot you want to delete and retrieve its ID:

    $ openstack share snapshot list
  2. Delete the snapshot:

    $ share snapshot delete <snapshot>
    • Replace <snapshot> with the name or ID of the snapshot you want to delete.

      Note

      Repeat this step for each snapshot you want to delete.

  3. After you delete the snapshot, run the following command to confirm that you deleted the snapshot:

    $ share snapshot list

6.6. Connecting to a shared network to access shares

When the driver_handles_share_servers parameter (DHSS) equals false, shares are exported to the shared provider network that your administrator has made available. You must connect your client, such as a Compute instance, to the shared provider network to access your shares.

In the following example procedure, the shared provider network is called StorageNFS. StorageNFS is configured when the Shared File Systems service (manila) is deployed with a CephFS-NFS back end. Follow similar steps to connect to the available network in your Red Hat OpenStack Services on OpenShift (RHOSO) deployment.

Note

The steps in the following example procedure use IPv4 addressing, but the steps are identical for IPv6.

Procedure

  1. Create a security group for the StorageNFS port that allows packets to egress the port but does not allow ingress packets from unestablished connections:

    $ openstack security group create no-ingress -f yaml
    created_at: '2018-09-19T08:19:58Z'
    description: no-ingress
    id: 66f67c24-cd8b-45e2-b60f-9eaedc79e3c5
    name: no-ingress
    project_id: 1e021e8b322a40968484e1af538b8b63
    revision_number: 2
    rules: 'created_at=''2018-09-19T08:19:58Z'', direction=''egress'', ethertype=''IPv4'',
     id=''6c7f643f-3715-4df5-9fef-0850fb6eaaf2'', updated_at=''2018-09-19T08:19:58Z''
     created_at=''2018-09-19T08:19:58Z'', direction=''egress'', ethertype=''IPv6'',
     id=''a8ca1ac2-fbe5-40e9-ab67-3e55b7a8632a'', updated_at=''2018-09-19T08:19:58Z''
  2. Create a port on the StorageNFS network with security enforced by the no-ingress security group.

    Note

    In the following example, the StorageNFS subnet on the StorageNFS network assigns IP address 198.51.100.160 to nfs-port0.

    $ openstack port create nfs-port0 \
      --network StorageNFS \
      --security-group no-ingress -f yaml
    
    admin_state_up: UP
    allowed_address_pairs: ''
    binding_host_id: null
    binding_profile: null
    binding_vif_details: null
    binding_vif_type: null
    binding_vnic_type: normal
    created_at: '2018-09-19T08:03:02Z'
    data_plane_status: null
    description: ''
    device_id: ''
    device_owner: ''
    dns_assignment: null
    dns_name: null
    extra_dhcp_opts: ''
    fixed_ips: ip_address='198.51.100.160', subnet_id='7bc188ae-aab3-425b-a894-863e4b664192'
    id: 7a91cbbc-8821-4d20-a24c-99c07178e5f7
    ip_address: null
    mac_address: fa:16:3e:be:41:6f
    name: nfs-port0
    network_id: cb2cbc5f-ea92-4c2d-beb8-d9b10e10efae
    option_name: null
    option_value: null
    port_security_enabled: true
    project_id: 1e021e8b322a40968484e1af538b8b63
    qos_policy_id: null
    revision_number: 6
    security_group_ids: 66f67c24-cd8b-45e2-b60f-9eaedc79e3c5
    status: DOWN
    subnet_id: null
    tags: ''
    trunk_details: null
    updated_at: '2018-09-19T08:03:03Z'
  3. Add nfs-port0 to a Compute instance.

    $ openstack server add port instance0 nfs-port0
    $ openstack server list -f yaml
    - Flavor: m1.micro
      ID: 0b878c11-e791-434b-ab63-274ecfc957e8
      Image: manila-test
      Name: demo-instance0
      Networks: demo-network=198.51.100.4, 10.0.0.53; StorageNFS=198.51.100.160
      Status: ACTIVE

    In addition to its private and floating addresses, the Compute instance is assigned a port with the IP address 198.51.100.160 on the StorageNFS network. You can use this IP address to mount NFS shares when access is granted to that address for the shares.

    Note

    You might need to adjust the networking configuration on the Compute instance, and then restart the services for the Compute instance to activate an interface with this address.

When the shared network to which shares are exported uses IPv6 addressing, you might experience an issue with DHCPv6 on the secondary interface. If this issue occurs, configure an IPv6 interface manually on the instance.

Prerequisites

  • Connection to a shared network to access shares

Procedure

  1. Log in to the instance.
  2. Configure the IPv6 interface address:

    $ sudo ip address add fd00:fd00:fd00:7000::c/64 dev eth1
  3. Activate the interface:

    $ sudo ip link set dev eth1 up
  4. Ping the IPv6 address in the export location of the share to test interface connectivity:

    $ ping -6  fd00:fd00:fd00:7000::21
  5. Alternatively, verify that you can reach the NFS server through Telnet:

    $ sudo dnf install -y telnet
    $ telnet fd00:fd00:fd00:7000::21 2049

6.8. Granting share access for end-user clients

Grant client access before mounting shares so users can read and write data.

The type of access depends on the protocol of the share:

  • For CIFS shares, use the CIFS user or group name.
  • For NFS shares, use the IP address of the Compute instance where you plan to mount the share.
  • For native CephFS shares, use Ceph client usernames for cephx authentication.

You can grant access to the share by using a command similar to the following command:

$ openstack share access create <share> <access_type> \
  --access-level <access_level>  <client_identifier>
  • Replace <share> with the share name or ID of the share you created.
  • Replace <access_type> with the type of access you want to grant to the share, for example, user for CIFS, ip for NFS, or cephfx for native CephFS.
  • Optional: Replace <access_level> with ro for read-only access. The default value is rw for read-write access.
  • Replace client_identifier with the IP address of the instance for NFS, user or group name for CIFS, or Ceph client username for native CephFS. For CIFS and native CephFS, you can use the same client_identifier across multiple clients.

6.8.1. Granting client access to NFS file system shares

You can provide access to NFS shares by using the IP address of the client Compute instance where you plan to mount the share.

Note

You can use the following procedure with IPv4 or IPv6 addresses.

Procedure

  • Retrieve the IP address of the client Compute instance where you plan to mount the share. Make sure that you select the IP address that corresponds to the network that can reach the shares. In this example, it is the IP address of the StorageNFS network:

    $ openstack server list -f yaml
    - Flavor: m1.micro
      ID: 0b878c11-e791-434b-ab63-274ecfc957e8
      Image: manila-test
      Name: demo-instance0
      Networks: demo-network=198.51.100.4, 10.0.0.53;
      StorageNFS=198.51.100.160
      Status: ACTIVE
    
    $ openstack share access create <share> ip 198.51.100.160
  • Replace <share> with the name or ID of the share you are granting access to.

    Note

    Access to the share has its own ID, id.

    +-----------------+---------------------------------------+
    | Property        | Value                                 |
    +-----------------+---------------------------------------+
    | access_key      | None
    | share_id        | db3bedd8-bc82-4100-a65d-53ec51b5cba3
    | created_at      | 2018-09-17T21:57:42.000000
    | updated_at      | None
    | access_type     | ip
    | access_to       | 198.51.100.160
    | access_level    | rw
    | state           | queued_to_apply
    | id              | 875c6251-c17e-4c45-8516-fe0928004fff
    +-----------------+---------------------------------------+

Verification

  • Verify that the access configuration was successful:

    $ openstack share access list <share>
    
    +--------------+-------------+--------------+--------------+--------+ ...
    | id           | access_type | access_to    | access_level | state  | ...
    +--------------+-------------+--------------+--------------+--------+
    | 875c6251-... | ip          | 198.51.100.160 | rw       	 | active | ...
    +--------------+------------+--------------+--------------+---------+ ...

6.8.2. Granting access to a native CephFS share

You can provide access to native CephFS shares by using Ceph client usernames for cephx authentication. The Shared File Systems service (manila) prevents the use of pre-existing Ceph users so you must create unique Ceph client usernames.

To mount a share, you need a Ceph client username and an access key. You can retrieve access keys by using the Shared File Systems service API. By default, access keys are visible to all users in a project namespace. You can provide the same user with access to different shares in the project namespace. Users can then access the shares by using the CephFS kernel client on the client machine.

Important

Use the native CephFS driver with trusted clients only.

Procedure

  1. Grant users access to a native CephFS share:

    $ openstack share access create <share> cephx <user>
    • Replace <share> with either the share name or share ID.
    • Replace <user> with the Ceph client username.
  2. Collect the access key for the user:

    $ openstack share access list <share>

6.8.3. Granting client access to CIFS file system shares

You can grant access to CIFS shares by using the usernames in the Active Directory service. The Shared File Systems service (manila) does not create new users on the Active Directory server. It only validates usernames through the security service, and access rules with invalid usernames result in an error status.

If the value of the driver_handles_share_servers (DHSS) parameter is set to true, then you can configure the Active Directory service by adding a security service. If the DHSS parameter is set to false, then your administrator has already configured the Active Directory service and associated it with the storage network.

To mount a share, you must specify the user’s Active Directory username and password. You cannot obtain this password through the Shared File Systems service.

Procedure

  • Grant users access to a CIFS share:

    $ openstack share access create <share> user <user>
    • Replace <share> with either the share name or the share ID.
    • Replace <user> with the username of the Active Directory user.

6.8.4. Revoking client access to a file system share

The owner of a share can revoke access to the share. Complete the following steps to revoke access that was previously granted to a share.

Procedure

  1. View the access list for the share to retrieve the access ID:

    $ openstack share access list <share_01>
    • Replace <share_01> with either the share name or share ID.
  2. Revoke access to the share:

    $ openstack share access delete <share_01> <875c6251-c17e-4c45-8516-fe0928004fff>
    • Replace <875c6251-c17e-4c45-8516-fe0928004fff> with the access ID of the share.
  3. View the access list for the share again to verify the share has been deleted:

    $ openstack share access list <share_01>
Note

If you have a client with read-write access to the share, you must revoke their access to the share, and then add a read-only rule if you want the client to have read-only access.

6.9. Mounting shares on Compute instances

After granting share access, clients can mount and use shares. Any client type can access shares with network connectivity.

The steps used to mount an NFS share on a virtual Compute instance are similar to the steps to mount an NFS share on a bare-metal Compute instance. For more information about how to mount shares on OpenShift containers, see Product Documentation for Red Hat OpenShift Container Platform.

Note

Client packages for the different protocols must be installed on the Compute instance that mounts the shares. For example, for the Shared File Systems service with CephFS-NFS, the NFS client packages must support NFS 4.1.

6.9.1. Listing Shared File Systems share export locations

Retrieve the export locations of shares so that you can mount a share.

Procedure

  • Retrieve the export locations of a share:

    $ openstack share export location list <share_01>
    • Replace <share_01> with either the share name or share ID.

      When multiple export locations exist, choose one for which the value of the preferred metadata field equals True. If no preferred locations exist, you can use any export location.

6.9.2. Viewing CephFS file system names for shares

If you need to provide the CephFS file system name as an option when you are mounting a native CephFS share, it is stored in the __mount_options metadata of the share.

Procedure

  • View the CephFS file system name:

    $ openstack share show <share_id>
    • Replace <share_id> with the share ID.

      Example output:

       +----------------------+--------------------------------------+
       | Property             | Value                                |
       +----------------------+--------------------------------------+
       | id                   | a3454cf1-bb1d-4e4d-a8e4-a3881c593720 |
       | size                 | 1                                    |
       | availability_zone    | manila-zone-0                        |
       | created_at           | 2024-09-26T14:53:18.153832           |
       | status               | shrinking                            |
       | name                 | docs_resize                          |
       | description          | None                                 |
       | project_id           | 1f31ee1c3e3c443bbf9aee5684456daa     |
       | snapshot_id          | None                                 |
       | share_network_id     | None                                 |
       | share_proto          | NFS                                  |
       | metadata             | {'__mount_options': 'fs=cephfs'}     |
       | share_type           | 303f0a73-711e-4beb-a4f7-a60acc1d588e |
       | is_public            | True                                 |
       | ...                  |                                      |

6.9.3. Mounting NFS, native CephFS, or CIFS shares

When you create NFS, native CephFS, or CIFS shares and grant share access to end-user clients, you can then mount the shares on the client to enable access to data, as long as there is network connectivity.

Prerequisites

  • To mount NFS shares, the nfs-utils package must be installed on the client machine.
  • To mount native CephFS shares, the ceph-common package must be installed on the client machine. Users access native CephFS shares by using the CephFS kernel client on the client machine.
  • To mount CIFS shares, the cifs-utils package must be installed on the client machine.

Procedure

  1. Log in to the instance:

    $ openstack server ssh demo-instance0 --login user
  2. Mount an NFS share. Refer to the following example for sample syntax:

    $ mount -t nfs \
      -v <198.51.100.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01>  \
      /mnt
  3. Mount a native CephFS share.

    1. Optional: Check the CephFS file system name before mounting the share:

      $ openstack share show <share_id>
      • Replace <share_id> with the share ID.
    2. Mount the share. Refer to the following example for sample syntax:

      $ mount -t ceph \
        <192.0.2.125:6789,192.0.2.126:6789,192.0.2.127:6789:/volumes/_nogroup/4c55ad20-9c55-4a5e-9233-8ac64566b98c> \
        -o name=<user>,secret='<AQA8+ANW/<4ZWNRAAOtWJMFPEihBA1unFImJczA==>'
  4. Mount a CIFS share. Refer to the following example for sample syntax:

    $ mount -t cifs \
      -o user=<user>,pass=<password> \
      <\\192.0.2.128/share_11265e8a_200c_4e0a_a40f_b7a1117001ed>
    • Replace <user> with the Active Directory user who has access to the share.
    • Replace <password> with the user’s Active Directory password.
    • Replace <\\192.0.2.128/share_11265e8a_200c_4e0a_a40f_b7a1117001ed> with the export location of the share.
    • Retrieve the export location as described in Section 6.9.1, “Listing Shared File Systems share export locations”.

Verification

  • Verify that the mount command succeeded:

    $ df -k

6.10. Transferring Shared File Systems share ownership

You can transfer NFS, native CephFS, or CIFS shares to another project when the share type extra specification, driver_handles_share_servers (DHSS), is set to false and the shares are not created in a share network.

You cannot transfer the following types of shares:

  • Shares that were created by using the DHSS=true share type.
  • Shares with CephX access rules because CephX users are assigned to a project, and they are unique in a Red Hat Ceph Storage cluster.
  • Shares that are in transitional states, possess replicas, or are in share groups.

Prerequisites

  • For native CephFS shares, all access rules must be removed prior to transferring.

Procedure

  1. Access the remote shell for the openstackclient pod from your workstation:

    $ oc rsh -n openstack openstackclient
  2. Create a share transfer:

    $ openstack share transfer create <share_id> --name <share_transfer_name>
    • Replace <share_id> with the ID of the share you want to transfer.
    • Replace <share_transfer_name> with a name for your share transfer.

      Example output:

      +------------------------+--------------------------------------+
      | Field                  | Value                                |
      +------------------------+--------------------------------------+
      | id                     | 1c56314e-7e97-455a-bbde-83828db038d4 |
      | created_at             | 2025-09-22T13:45:41.376091           |
      | name                   | share-transfer                       |
      | resource_type          | share                                |
      | resource_id            | 4f508574-e1c8-4bf9-adc4-8a1d34ac13a6 |
      | source_project_id      | 7dd704e2ab5c42c0afe83bfad076fcb4     |
      | destination_project_id | None                                 |
      | accepted               | False                                |
      | expires_at             | 2025-09-22T13:50:41.375594           |
      | auth_key               | af429e22e0abc31d                     |
      +------------------------+--------------------------------------+
    • Store the transfer id and auth_key to share with the user in a different project so they can accept the share transfer. You must save the transfer ID when you create the transfer because you cannot obtain the auth_key from the service again later. If you do not have the auth_key to share with another user later, you must delete the transfer and start the process again.
  3. View a list of share transfers in your project to verify that your share transfer is created:

    $ openstack share transfer list

    Example output:

    +--------------------------------------+----------------+---------------+--------------------------------------+
    | ID                                   | Name           | Resource Type | Resource Id                          |
    +--------------------------------------+----------------+---------------+--------------------------------------+
    | 1c56314e-7e97-455a-bbde-83828db038d4 | share-transfer | share         | 4f508574-e1c8-4bf9-adc4-8a1d34ac13a6 |
    +--------------------------------------+----------------+---------------+--------------------------------------+
  4. View details of the share transfer:

    $ openstack share transfer show <share_transfer_id>
    • Replace <share_transfer_id> with the share transfer ID, for example 1c56314e-7e97-455a-bbde-83828db038d4.

      Example output:

      +------------------------+--------------------------------------+
      | Field                  | Value                                |
      +------------------------+--------------------------------------+
      | id                     | 181773b2-e359-45f4-9d7d-31ee8b722fd3 |
      | created_at             | 2025-09-22T13:45:41.376091           |
      | name                   | share-transfer                       |
      | resource_type          | share                                |
      | resource_id            | 4f508574-e1c8-4bf9-adc4-8a1d34ac13a6 |
      | source_project_id      | 7dd704e2ab5c42c0afe83bfad076fcb4     |
      | destination_project_id | None                                 |
      | accepted               | False                                |
      | expires_at             | 2025-09-22T13:50:41.375594           |
      +------------------------+--------------------------------------+
    • To delete a share transfer, you can run the following command:

      $ openstack share transfer delete <share_transfer_id>
  5. Exit the openstackclient pod:

    $ exit
  6. Share the transfer id and auth_key with the user who accepts the share transfer in a different project.

    • The user accepts the share transfer by using the following command. In this example, 1c56314e-7e97-455a-bbde-83828db038d4 is the share transfer ID and af429e22e0abc31d is the authorization key:

      Example:

      $ openstack share transfer accept 1c56314e-7e97-455a-bbde-83828db038d4  af429e22e0abc31d

6.11. Deleting Shared File Systems service shares

The Shared File Systems service (manila) provides no protection to prevent you from deleting your data. The service does not check whether clients are connected or workloads are running. When you delete a share, you cannot retrieve it.

Warning

Back up your data before you delete a share.

Prerequisites

  • If you created snapshots from a share, you must delete all of the snapshots and replicas before you can delete the share. For more information, see Deleting a snapshot.

Procedure

  • Delete a share:

    $ openstack share delete <share>
    • Replace <share> with either the share name or the share ID.

6.12. Listing resource limits of the Shared File Systems service

You can list the current resource limits for the Shared File Systems service (manila) in a project to plan workloads and prepare for any operations based on resource consumption.

Procedure

  • List the resource limits and current resource consumption for the project:

    $ openstack share limits show --absolute

6.13. Troubleshooting Shared File Systems operation failures

Run command-line queries to troubleshoot errors when creating or mounting shares.

6.13.1. Viewing error messages for file system shares

You can use the command line to retrieve user support messages if a share shows an error status.

Procedure

  1. When you create a share, run the following command to view the status of the share:

    $ openstack share list
  2. If the status of your share shows an error, run the share message list command. You can use the --resource-id option to filter to the specific share you want to find out about:

    $ openstack share message list [--resource-id]
  3. Check the User Message column in the share message list command output for a summary of the error.
  4. To view more details about the error, run the message show command, followed by the message ID from the message list command output:

    $ openstack share message show <id>
    • Replace <id> with the message ID from the message list command output.

6.13.2. Debugging Shared File Systems share mount failures

You can use these verification steps to identify the root cause of an error when you mount shares.

Procedure

  1. Verify the access control list of the share to ensure that the rule that corresponds to your client is correct and has been successfully applied:

    $ openstack share access list <share_01>
    • Replace <share_01> with either the share name or share ID.

      In a successful rule, the state attribute equals active.

  2. If the share type parameter is configured to driver_handles_share_servers=false, copy the hostname or IP address from the export location and ping it to confirm connectivity to the NAS server:

    Example:

    $ ping -c 1 198.51.100.13
    PING 198.51.100.13 (198.51.100.13) 56(84) bytes of data.
    64 bytes from 198.51.100.13: icmp_seq=1 ttl=64 time=0.048 ms--- 198.51.100.13 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 7.851/7.851/7.851/0.000 ms
  3. If you are using the NFS protocol, you can verify that the NFS server is ready to respond to NFS RPC calls on the correct port:

    $ rpcinfo -T tcp -a 198.51.100.13.8.1 100003 4
    program 100003 version 4 ready and waiting
    Note

    The IP address is written in universal address format (uaddr), which adds two extra octets (8.1) to represent the NFS service port, 2049.

If these verification steps fail, there might be a network connectivity issue or an issue with the back-end storage for the Shared File Systems service (manila). Collect the log files and contact Red Hat Support.

Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red Hat
Volver arriba