Kubernetes failed to resolve mounted device devdsk1 2 No such file or directory

Kubernetes: failed to resolve mounted device /dev/dsk1: 2 (No such file or directory)

Problem Description

In a Kubernetes based environment where a file based storage device is being used, the following message is repeated frequently in the aerospike.log file:

Feb 20 2020 16:22:49 GMT: WARNING (hardware): (hardware.c:2258) failed to resolve mounted device /dev/dsk1: 2 (No such file or directory)


When a file based storage-engine is in use the Aerospike hardware module code will try and look up the parent device for the filesystem in use. The following scenarios can trigger this check to be executed.

  • Checking namespace stats via an info call e.g.
    • storage device stats
    • index device stats (all-flash which has mount points) or pmem mount points (can occur anytime the “namespace/” info command is called)
  • Once during Aerospike daemon (asd) startup if using pmem devices.
  • Setting scheduler for storage devices.

Most commonly, the check would be triggered by checking namespace statistics when populating the metrics for device age or lifetime. These are:

Specifically, the warning is caused in a Docker or Kubernetes environment as the parent device (such as /dev/sda) is not visible inside the container. However, the same parent devices for the mount points can be seen using:

cat /proc/mounts



Aerospike code uses /proc/mounts to get the parent device for the filesystem in use.

It should be noted that this warning should not happen in the case of using block devices directly (volumeMode: Block in the Aerospike Helm chart values.yaml file), because in that scenario the device path will be accessible directly in /dev/ inside the container.

In an environment where file based storage is being used, if the warnings are displayed with a high frequency it is most likely due to periodic info calls. Normally containers do not have access or direct visibility to the devices attached to the host. In a standard Docker setup, the --device option can be used to access the block device inside the container. Alternately the container can be run in --privileged mode which will allow the container to access all devices attached to the host.

In a Kubernetes managed environment, there is no option like --device however the container and pods can be run in privileged mode. So by deploying the aerospike statefulset with the container in privileged mode, this warning can be suppressed.


The current solution is to deploy the containers in privileged mode as shown below:


- name: aerospike


privileged: true



There is a caveat as this is not an ideal configuration from a security point of view. This is why this configuration is not the default.


  • More detail on deploying Docker within Kubernetes in privileged mode can be found at the link below:

  • There is an extant feature request to move the warning in question to the detail log level so that it does not flood the logs in scenarios such as those described above.




February 2020

© 2015 Copyright Aerospike, Inc. | All rights reserved. Creators of the Aerospike Database.