Menu Close
Settings Close

Language and Page Formatting Options

Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

Chapter 4. File Shares

The OpenStack Shared File Systems service (openstack-manila) provides the means to easily provision shared file systems that can be consumed by multiple instances. In the past, OpenStack users needed to manually deploy shared file systems before mounting them on instances. The OpenStack Shared File Systems service, on the other hand, allows users to easily provision shares from a pre-configured storage pool, ready to be mounted securely. This pool, in turn, can be independently managed and scaled to meet demand.

4.1. Back Ends

When deploying Red Hat OpenStack Platform for the environment, we recommend using the director. Doing so helps ensure the proper configuration of each service, including the Shared File System service (and, by extension, its back end). The director also has several integrated back end configurations:

For a complete list of supported back end appliances and drivers, see Component, Plug-In, and Driver Support in RHEL OpenStack Platform.

4.2. Create and Manage Share Types

When creating a share on a non-default back end, you need to explicitly specify which back end to use. To make the process seamless for users, create a share type and associate it with the share_backend_name value of each back end. To create a share type named SHARETYPE, run the following as an OpenStack admin:

# manila type-create --is_public false SHARETYPE DHSS

DHSS (or driver handles share servers) specifies whether the share type will use drivers that handle share servers. This should match the value of driver_handles_share_servers in your back end definition (true or false).

The --is_public false option indicates that the share type should not be accessible to the public. If you want the share type to be public, remove this option.

For example, to create a non-public share type named general based on a back end configured with driver_handles_share_servers=false:

# manila type-create --is_public false general false

After creating the share type, you can map it to a back end. To do so:

# manila type-key SHARETYPE set share_backend_name='SHAREBACKEND'

Replace SHAREBACKEND with the name of the back end — specifically, its share_backend_name value. With this, the Shared File System Service will use the SHAREBACKEND back end whenever you invoke SHARETYPE during share creation (as in Section 4.3, “Create a Share”). For example, to map the share type general to the back end cdotSingleSVM:

# manila type-key general set share_backend_name='cdotSingleSVM'

As an OpenStack admin, you can prevent users from creating public share types through the dashboard. See Section 4.9, “Disable Creation of Public Shares and Share Types Through the Dashboard” for related information.

With this release, the Shared File System Service only supports NetApp storage controllers as back ends. See Creating and Defining Manila Share Types for information on extra specs supported by NetApp.

4.3. Create a Share

To create a share, log in to the Shared File System service host and run:

# manila create --share-type SHARETYPE --name SHARENAME PROTO GB


  • SHARETYPE applies settings associated with the specified share type.
  • SHARENAME is the name of the share.
  • PROTO is the share protocol you want to use.
  • GB is the size of the share, in GB.

For example, in Section 4.2, “Create and Manage Share Types” we created a share type named general, which we mapped to the back end cdotSingleSVM. To create a 1 GB NFS share named share-01 on the cdotSingleSVM back end , run:

# manila create --share-type general --name share-01 nfs 10
 | Property          | Value                                |
 | status            | creating                             |
 | description       | None                                 |
 | availability_zone | nova                                 |
 | share_network_id  | None                                 |
 | export_locations  | []                                   |
 | share_server_id   | None                                 |
 | host              | None                                 |
 | snapshot_id       | None                                 |
 | is_public         | False                                |
 | id                | d760eee8-1d91-48c4-8f9a-ad07072e17a2 |
 | size              | 10                                   |
 | name              | share-01                             |
 | share_type        | 8245657b-ab9e-4db1-8224-451c32d6b5ea |
 | created_at        | 2015-09-29T16:27:54.092272           |
 | export_location   | None                                 |
 | share_proto       | NFS                                  |
 | project_id        | a19dc7ec562c4ed48cea58d22eb0d3c7     |
 | metadata          | {}                                   |

4.4. List Shares and Export Information

To verify that the shares were created successfully:

# manila list
 | ID                                   | Name     | ... | Status    ...
 | d760eee8-1d91-48c4-8f9a-ad07072e17a2 | share-01 | ... | available ...

The manila list command will also display the export location of the share:

 | Export location                                             ...

This information will be used later when mounting the share (Section 4.7, “Mount a Share on an Instance”).

4.5. Grant Share Access

Before you can mount a share on an instance, grant the instance access to the share first:

# manila access-allow SHAREID IDENT IDENTKEY


  • SHAREID is the ID of the share created in Section 4.3, “Create a Share”.
  • IDENT is the method that the Shared File System service should use to authenticate a share user or instance.
  • The IDENTKEY varies depending on what identifying method you choose as IDENT:

    • cert: this method is used for authenticating an instance through TLS certificates.
    • user: use this to authenticate by user or group name.
    • ip: use this to authenticate an instance through its IP address.

For example, to grant read-write access to an instance (identified by the IP, run:

# manila access-allow d760eee8-1d91-48c4-8f9a-ad07072e17a2 ip
 | Property     | Value                                |
 | share_id     | d760eee8-1d91-48c4-8f9a-ad07072e17a2 |
 | deleted      | False                                |
 | created_at   | 2015-09-29T16:35:33.862114           |
 | updated_at   | None                                 |
 | access_type  | ip                                   |
 | access_to    |                          |
 | access_level | rw                                   |
 | state        | new                                  |
 | deleted_at   | None                                 |
 | id           | b4e990d7-e9d1-4801-bcbe-a860fc1401d1 |

Note that access to the share has its own ID (ACCESSID), b4e990d7-e9d1-4801-bcbe-a860fc1401d1.

To verify that the access configuration was successful:

# manila access-list d760eee8-1d91-48c4-8f9a-ad07072e17a2
 | id                        |access type|access to  | access level ...
 |b4e990d7-e9d1-4801-bcbe-...|ip         || rw           ...

4.6. Revoke Access to a Share

To revoke previously-granted access to a share, you need to delete the access to the share:

# manila access-deny SHAREID ACCESSID

For example, to revoke the access granted earlier in Section 4.5, “Grant Share Access”:

# manila access-list d760eee8-1d91-48c4-8f9a-ad07072e17a2
 | id                        |access type|access to  | access level ...
 |b4e990d7-e9d1-4801-bcbe-...|ip         || rw           ...
# manila access-deny d760eee8-1d91-48c4-8f9a-ad07072e17a2 b4e990d7-e9d1-4801-bcbe-a860fc1401d1

At this point, the instance will no longer be able to use the mounted share.

4.7. Mount a Share on an Instance

After configuring the share to authenticate an instance, you can then mount the share. For example, to mount the share from Section 4.3, “Create a Share” to /mnt on the instance from Section 4.5, “Grant Share Access”, log in to the instance and mount as normal:

# ssh root@
# mount -t nfs -o vers=3 /mnt

See Section 4.4, “List Shares and Export Information” to learn how to view a share’s export information.

4.8. Delete a Share

To delete a share:

# manila delete SHAREID

For example:

# manila delete d760eee8-1d91-48c4-8f9a-ad07072e17a2

4.9. Disable Creation of Public Shares and Share Types Through the Dashboard

The dashboard allows users to set shares or share types as public during creation through checkboxes. When creating a share, the Make visible for all checkbox sets the share as public:

share default cropped

The share type creation interface features a Public checkbox that does the same:

share type public default cropped

You can disable these checkboxes to limit the number of public shares and share types created by users. To do so, log in to a Controller node and add the following to /etc/openstack-dashboard/local_settings:

    'enable_public_shares': False
    'enable_public_share_type_creation': False, }

The 'enable_public_shares':False setting disables the Make visible for all checkbox. Likewise, 'enable_public_share_type_creation':False disables the Public checkbox in the share type creation interface.

If you deployed OpenStack with High Availability, apply the same change to all Controller nodes. Then, restart the httpd service from any Controller node:

# pcs resource restart httpd-clone

Otherwise, restart the httpd service using:

# systemctl restart httpd

To view your changes, reload your dashboard. The checkboxes should no longer appear in their respective interfaces.


Disabling these checkboxes does not prevent users or OpenStack admins from setting shares or share types to public after creating them.