🦭 Podman Error: 'lsetxattr operation not supported' Pulling or Extracting an Image

Exact Error Message

Error: writing blob: adding layer with blob "sha256:5b1423465504...":
processing tar file(lsetxattr /home/jane/.local/share/containers/storage/overlay/
a3f9.../diff/usr/bin/ping user.overlay.opaque: operation not supported): exit status 1

Depending on which layer trips first, you may instead see the security namespace:

Error: copying system image from manifest list: writing blob: adding layer with blob
"sha256:9c1b6dd6c1e6...": ApplyLayer exit status 1 stdout:  stderr:
lsetxattr /var/lib/containers/storage/overlay/f01c.../diff/usr/bin/newgidmap
security.capability: operation not supported

What It Means

Podman’s default storage driver, overlay, reconstructs image layers on disk and needs extended attributes (xattrs) to do it faithfully. It writes user.overlay.* attributes to record whiteouts and opaque directories, and it replays security.capability attributes so that binaries like ping and newuidmap keep their file capabilities inside the container. The lsetxattr syscall is how those attributes get set, and operation not supported is EOPNOTSUPP coming straight back from the filesystem underneath your graphroot.

That means this is almost never a Podman bug or a corrupt image — it is a property of the filesystem where container storage lives. Network filesystems (NFS, CIFS/SMB), some fuse-based and encrypted home directories, and non-POSIX filesystems like exFAT or FAT32 either implement no xattrs at all or implement only a subset that excludes the user.* or security.* namespaces. Rootless Podman makes this far more common than rootful, because the rootless graphroot defaults to ~/.local/share/containers/storage — and on managed workstations, CI runners, and HPC login nodes that home directory is frequently a network mount. The fix is either to move storage onto a local POSIX filesystem or to switch to a driver that does not need xattrs.

Common Causes

• The rootless graphroot sits in a home directory mounted over NFS, where user.* xattrs are unsupported or silently disabled.
• Storage lives on a CIFS/SMB share, an exFAT/FAT32 external disk, or a VirtualBox/VMware shared folder.
• An encrypted or fuse-backed home (gocryptfs, ecryptfs, some sshfs setups) passes through only a subset of xattr namespaces.
• The mount is present but mounted with options that strip xattrs, such as nfs without nfs4 xattr support or user_xattr disabled on an older ext filesystem.
• A custom graphroot in storage.conf was pointed at a shared volume for convenience without checking filesystem type.
• A container-in-container or CI workspace bind-mounts the storage path from a host directory backed by an overlay or network volume.

Diagnostic Commands

Ask Podman where its storage actually is, since the rootless override often differs from the system file:

podman info --format '{{.Store.GraphRoot}} {{.Store.GraphDriverName}}'
podman info --format '{{.Store.RunRoot}}'

Identify the filesystem type backing that path — this is usually the whole answer:

stat -f -c %T ~/.local/share/containers/storage
findmnt -T ~/.local/share/containers/storage

Test xattr support directly rather than inferring it. If setfattr fails here, overlay cannot work there:

touch ~/.local/share/containers/storage/xattr-probe
setfattr -n user.test -v 1 ~/.local/share/containers/storage/xattr-probe
getfattr -d ~/.local/share/containers/storage/xattr-probe
rm ~/.local/share/containers/storage/xattr-probe

Compare against a known-good local path to confirm the problem is the filesystem, not the tooling:

touch /var/tmp/xattr-probe && setfattr -n user.test -v 1 /var/tmp/xattr-probe && echo "xattrs OK on /var/tmp"

Show which configuration files Podman is merging, so you know which one to edit:

ls -l /etc/containers/storage.conf ~/.config/containers/storage.conf
podman info --format '{{.Store.ConfigFile}}'

Step-by-Step Resolution

1. Confirm the diagnosis. stat -f -c %T returning nfs, smb2, exfat, msdos, or fuseblk alongside a failing setfattr means the filesystem is the cause and no Podman flag will make overlay work there:

stat -f -c %T ~/.local/share/containers/storage

2. Pick a local POSIX destination with room for images. On most hosts /var/tmp or a dedicated /srv mount on ext4 or xfs is available even when $HOME is not local:

sudo mkdir -p /srv/podman/jane
sudo chown jane:jane /srv/podman/jane
stat -f -c %T /srv/podman/jane   # expect ext2/ext3 (ext4) or xfs

3. Point rootless storage at that path by creating or editing the rootless override, which takes precedence over /etc/containers/storage.conf for your user:

# ~/.config/containers/storage.conf
[storage]
driver = "overlay"
graphroot = "/srv/podman/jane"
runroot = "/run/user/1000/containers"

4. Reset the old, partially populated storage so Podman does not try to reuse layers from the unusable location. This deletes local images and containers, so pull them again afterwards:

podman system reset
podman info --format '{{.Store.GraphRoot}} {{.Store.GraphDriverName}}'
podman pull docker.io/library/alpine:latest

5. If you cannot relocate storage — locked-down NFS home, no local scratch space — fall back to the vfs driver, which copies each layer in full instead of using overlay metadata and therefore never calls lsetxattr for overlay attributes:

# ~/.config/containers/storage.conf
[storage]
driver = "vfs"
graphroot = "/home/jane/.local/share/containers/storage"

6. Verify end to end with a pull and a run, and check disk usage if you chose vfs, because a full image tree is duplicated per layer:

podman pull docker.io/library/fedora:latest
podman run --rm docker.io/library/fedora:latest cat /etc/os-release
podman system df

Note the tradeoff in step 5 honestly: vfs can consume several times the disk of overlay for a multi-layer image and makes pulls noticeably slower, because every layer is a full copy of the one below it. It is a correctness fallback, not a performance choice. For long-lived build hosts, relocating the graphroot is always the better answer.

For generating a storage.conf tailored to your mount layout and available local disks, the Podman storage prompts in the prompt library can produce a reviewed configuration.

Prevention

• Provision container hosts with a local ext4 or xfs partition for /var/lib/containers and rootless scratch space before deploying Podman.
• In your image or golden config, ship a ~/.config/containers/storage.conf that pins graphroot to a known-local path rather than relying on $HOME.
• Add a stat -f -c %T plus setfattr probe to host provisioning checks so a network home is caught before the first pull.
• Keep runroot on /run/user/$UID, which is tmpfs and always local, rather than under a network home.
• On CI runners, mount a local volume at the graphroot path in the job template instead of inheriting the workspace filesystem.
• Document the vfs fallback and its disk cost so operators do not silently enable it on hosts with small root volumes.

Related Errors

• there might not be enough IDs available in the namespace — subuid/subgid range too small, unrelated to xattrs; see Podman error: insufficient UIDs in user namespace.
• newuidmap: write to uid_map failed — the setuid helper cannot map ranges, a user-namespace setup failure rather than storage; see Podman error: newuidmap exit status 1.
• permission denied on a bind-mounted volume — usually SELinux labelling, not extended attributes; see Podman error: SELinux AVC denied on volume mount.
• no space left on device during a pull — the graphroot filesystem is full, a capacity problem that often appears right after switching to vfs.

Frequently Asked Questions

Can I keep overlay and just mount NFS differently? Not reliably. Even NFSv4 servers that expose some xattrs typically do not support the user.* and security.* namespaces overlayfs requires, and support varies by server implementation. Treat a network graphroot as unsupported for overlay and relocate instead.

Is fuse-overlayfs a workaround? It changes which component performs the overlay work, but it still needs the underlying filesystem to store extended attributes, so a filesystem returning EOPNOTSUPP from lsetxattr fails the same way. The filesystem, not the overlay implementation, is the constraint.

How much extra disk does vfs actually use? Roughly the sum of every layer expanded independently, so an image with eight layers can occupy several times its overlay footprint. Run podman system df after a few pulls and size the volume accordingly, and prune aggressively with podman image prune.

Do I have to run podman system reset after moving the graphroot? Not strictly, but the old location keeps its images and a half-written layer tree that can confuse later pulls, and Podman will not migrate content for you. Resetting gives a clean start; re-pull your images afterwards. For more container-runtime fixes, see the Podman guides.