Filesystem actions in containers fail with `Too many levels of symbolic links`
This document (000020104) is provided subject to the disclaimer at the end of this document.
Environment
Situation
When attempting to perform a filesystem action inside a container with a volume located on an autofs directory, the error Too many levels of symbolic links is thrown and the action fails.
bash: cd: /data: Too many levels of symbolic links
Resolution
Docker
Mount the volume in question with the flag slave, rslave, shared, or rshared to ensure that mount changes are propagated to the container.
Example:
docker run -d -v /path/to/autofs:/data:shared ubuntu
See the links at the bottom of this article for info on what each of these flags does
Kubernetes
Define mountPropagation for the volume in question as either HostToContainer (same as Docker's rslave) or Bidirectional (same as Docker's rshared):
kind: Pod
apiVersion: v1
metadata:
name: test-app
spec:
containers:
- name: test
image: busybox
volumeMounts:
- mountPath: "/data"
name: test-app-vol
mountPropagation: HostToContainer
volumes:
- name: test-app-vol
hostPath:
path: /data
Cause
With the default Docker bind-mount propagation of
rprivate, containers do not receive mount changes for volumes from the host.
Additional Information
Kubernetes mountPropagation - https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation
Linux Kernel Shared Subtree - https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt
Disclaimer
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:000020104
- Creation Date: 06-May-2021
- Modified Date:25-Jun-2024
-
- SUSE Rancher
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com
