containerd/containerd · critical

%s does not support d_type. If the backing filesystem is xfs

Error message

%s does not support d_type. If the backing filesystem is xfs, please reformat with ftype=1 to enable d_type support

What it means

NewSnapshotter refuses to start the overlayfs snapshotter when the backing filesystem of the given root does not support d_type in readdir results. overlayfs requires d_type; without it, overlay mounts will fail at runtime, so construction fails fast. The message specifically calls out xfs formatted without ftype=1.

Source

Thrown at plugins/snapshots/overlay/overlay.go:137

// diffs are stored under the provided root. A metadata file is stored under
// the root.
func NewSnapshotter(root string, opts ...Opt) (snapshots.Snapshotter, error) {
	var config SnapshotterConfig
	for _, opt := range opts {
		if err := opt(&config); err != nil {
			return nil, err
		}
	}

	if err := os.MkdirAll(root, 0700); err != nil {
		return nil, err
	}
	supportsDType, err := fs.SupportsDType(root)
	if err != nil {
		return nil, err
	}
	if !supportsDType {
		return nil, fmt.Errorf("%s does not support d_type. If the backing filesystem is xfs, please reformat with ftype=1 to enable d_type support", root)
	}
	if config.ms == nil {
		config.ms, err = storage.NewMetaStore(filepath.Join(root, "metadata.db"))
		if err != nil {
			return nil, err
		}
	}

	if err := os.Mkdir(filepath.Join(root, "snapshots"), 0700); err != nil && !os.IsExist(err) {
		return nil, err
	}

	if !hasOption(config.mountOptions, "userxattr") {
		// figure out whether "userxattr" option is recognized by the kernel && needed
		userxattr, err := overlayutils.NeedsUserXAttr(root)
		if err != nil {
			log.L.WithError(err).Warnf("cannot detect whether \"userxattr\" option needs to be used, assuming to be %v", userxattr)
		}

View on GitHub (pinned to 4246446a2b)

Solutions

1. Reformat the backing xfs filesystem with ftype=1: mkfs.xfs -n ftype=1 /dev/<dev> (requires unmounting and migrating data)
2. Move containerd/docker root (e.g. /var/lib/containerd) to a filesystem that supports d_type
3. Verify with 'xfs_info <mount> | grep ftype' — ftype=0 confirms the diagnosis
4. As a fallback use a different snapshotter (e.g. native) which does not require d_type

Example fix

// before
mkfs.xfs /dev/sdb1
// after
mkfs.xfs -n ftype=1 /dev/sdb1

// Go: check d_type support before constructing the snapshotter
supportsDType, err := fs.SupportsDType(root)
if err != nil || !supportsDType {
    return errors.New("backing filesystem does not support d_type; reformat xfs with ftype=1")
}
sn, err := overlay.NewSnapshotter(root)

sn, err := overlay.NewSnapshotter(root)
if err != nil {
    if strings.Contains(err.Error(), "does not support d_type") {
        return fmt.Errorf("reformat %s with ftype=1 or use another FS/snapshotter: %w", root, err)
    }
    return err
}

When it happens

Trigger: Calling overlay.NewSnapshotter(root) (plugins/snapshots/overlay/overlay.go:137) where root resides on xfs with ftype=0, or another filesystem lacking d_type (some older ext4/SD cards, certain tmpfs configurations). fs.SupportsDType returned false.

Common situations: Docker/containerd data-root placed on an xfs volume formatted with ftype=0 (common with old mkfs defaults or some RHEL hosts); running containers on /var/lib mounted from such a volume; ARM boards with d_type-less filesystems.

Related errors

• mount options is too long
• is a directory
• failed to get reader from content store: %w
• failed to activate mounts: %w
• errdefs.ErrInvalidArgument

AI-assisted analysis of containerd/containerd@4246446a2b (2026-09-02). Data as JSON: /api/errors/4952060592c052b4. Report an issue: GitHub.