Dash Enterprise Administration
4.3.1
4.3.1
  • Changelog
  • Installation
    • Capacity Planning
      • Dash Enterprise Single Server
      • Dash Enterprise for Kubernetes
    • Before you install
    • Dash Enterprise Single Server
      • Installation on cloud provider
      • On-premise installation on own server
      • Fully offline installation
    • Dash Enterprise Kubernetes
      • Amazon Web Services resource prerequisites
      • Google Cloud Platform resource prerequisites
      • Microsoft Azure resource prerequisites
  • Configuration
    • Set up your Server Manager
    • Run preflight checks
    • Configure basic settings
    • Authentication settings
      • Built-in local authentication
      • LDAP authentication
      • SAML authentication
    • Dash Enterprise Kubernetes additional required configuration
    • Configure optional settings
    • Add SELinux permissions to mapped directories
    • Other options and customizations
    • Using Snapshots & Backups
    • Running and logging into Dash Enterprise
    • Next steps
  • Advanced Configuration
    • General troubleshooting and problem solving
      • Dash Enterprise Kubernetes
    • Load balancer configuration
    • Reverse proxy setup instructions
    • Docker storage driver requirements and considerations
    • Import an LDAPS certificate from Active Directory into Dash Enterprise
    • Transfer Dash Enterprise to a new server
    • Sync license changes
    • Change channels for an upgrade
    • Admin panel reference
    • Configure Dash Enterprise to use common SAML IdPs
      • Active Directory Federation Services (AD FS)
      • PingFederate
      • Okta
    • Configure Dash Enterprise to use common LDAP IdPs
      • Okta
  • Upgrade
    • Prepare for the upgrade
    • Upgrade
      • Dash Enterprise Single Server
      • Dash Enterprise for Kubernetes
    • After the upgrade
  • Advanced Troubleshooting
    • Dash Enterprise Architecture and Internals
    • Navigating the System
    • Navigating the Support Bundle
    • Getting Help and Reporting Issues
    • Troubleshooting Specific Issues
Powered by GitBook
On this page
  • Operating system, distribution, and Docker edition
  • Backing filesystem (where /var/lib/docker is located)
  • Further considerations and cautions

Was this helpful?

  1. Advanced Configuration

Docker storage driver requirements and considerations

Docker images consist of a series of read-only layers, each representing an instruction in the image's Dockerfile. When Docker creates a container from an image, it creates a new writable layer (container layer) on top of the underlying image layers. The storage driver configured in Docker determines how your host system interacts with these layers.

Typical Docker setups will automatically configure the most appropriate storage driver for a given system. You can determine which storage driver is being used by running docker info on the host machine, which will return output similar to:

docker info

which outputs:

Containers: 0
Images: 0
Storage Driver: overlay
 Backing Filesystem: extfs
...

In this example, Docker is using the overlay storage driver.

A storage driver sometimes needs to be explicitly configured for a given system, depending on the following:

  • The host’s operating system, distribution, and Docker edition

  • The backing filesystem (i.e. where /var/lib/docker is located)

Operating system, distribution, and Docker edition

overlay2 is the recommended storage driver whenever possible, but any of the below should work:

  • Ubuntu: aufs, devicemapper, overlay2 (Ubuntu 14.04.4 or later, 16.04 or later), overlay, zfs, vfs

  • Debian: aufs, devicemapper, overlay2 (Debian Stretch), overlay, vfs

  • CentOS: devicemapper, vfs, overlay2 (if xfs created with d_type=true)

  • RHEL: devicemapper, vfs, overlay2 (if xfs created with d_type=true)

  • Fedora: devicemapper, overlay2 (Fedora 26 or later, experimental), overlay (experimental), vfs

Please contact Plotly support if you need help configuring a storage driver while using a Docker edition other than Docker CE.

Backing filesystem (where /var/lib/docker is located)

Specific backing filesystems are required for some storage drivers:

Storage driver
Supported backing filesystems

overlay, overlay2

ext4, xfs

aufs

ext4, xfs

devicemapper

direct-lvm

btrfs

btrfs

zfs

zfs

Further considerations and cautions

Occasionally, storage drivers may have additional prerequisites that could render them incompatible with your system or require additional system configuration. This includes kernel version requirements as well as filesystem formatting. For example, the xfs backing filesystem is supported for the overlay storage driver, as long as d_type=true is set you can verify that with xfs_info /mount-point The 3rd column of the 6th line of the xfs_info output is the most interesting because it contains the parameter ftype which should be 1. When ftype is 0, d_type support is disabled. When it is 1, d_type support is enabled and you're safe to use the overlay(2) storage driver with Docker on an XFS filesystem.

Example of Terminal output:

$ xfs_info /mount-point

meta-data=/mount-point isize=512    agcount=4, agsize=2620928 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=10483712, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1 <<--- This is the line you are looking for
log      =internal               bsize=4096   blocks=5119, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
PreviousReverse proxy setup instructionsNextImport an LDAPS certificate from Active Directory into Dash Enterprise

Last updated 2 years ago

Was this helpful?

Additionally, some backing filesystems will require additional configuration depending on the host system’s OS and kernel version, as discussed in .

Running the devicemapper storage driver in loopback mode is highly unstable and not recommended for production systems. Instead, configure devicemapper in direct-lvm mode as described in . (Note that devicemapper is the default storage driver for Centos 7/RHEL 7 systems.)

See for additional information on storage drivers and selection/configuration.

the Docker storage driver documentation
Further considerations and cautions
Dash app manager boot failure