Error on copy to a tmpfs backend

LXD
1

Hi. I would like to be able to create ephemeral copies of unprivileged LXD 4 containers in tmpfs on Ubuntu 20.04.2. I attempted the following on a freshly installed system, kernel 5.8.0-53, LXD 4.0.6, but got an error. Are you able to help me troubleshoot?

lxc launch images:ubuntu/focal/amd64 u2004
sudo mount -t tmpfs -o size=2G,uid=1000,gid=1000 ramdisk ~/.ramdisk
lxc storage create ram dir source=/home/user/.ramdisk
lxc copy u2004 u2004-e --instance-only -e -s ram

Error: Create instance from copy: Create instance volume from copy failed: [Rsync send failed: u2004, /var/snap/lxd/common/lxd/storage-pools/u1/containers/u2004/: [exit status 23 read unix @lxd/750cec4f-5311-4c66-9813-0484d03bb26f->@: use of closed network connection] (rsync: rsync_xal_set: lsetxattr(“”/var/snap/lxd/common/lxd/storage-pools/ram/containers/u2004-e/rootfs/var/log/journal/5e4ff19e548b4a8ca830426e6086c9ca/.system.journal.4yAKtH"",“user.crtime_usec”) failed: Operation not supported (95)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1196) [sender=3.1.2]
)]

Everything works fine without “-s ram”. It also works with it but without mounting that folder as tmpfs.

Thank you.

2

Perhaps tmpfs doesn’t support the required user extended attributes to accurately copy the problem file in question:

https://www.man7.org/linux/man-pages/man5/tmpfs.5.html

" The tmpfs filesystem supports extended attributes (see xattr(7)), but user extended attributes are not permitted."

3

Thank you! Now I recall years ago I had to do something with extended attributes for the tmpfs mount point for a similar setup, but for LXC on Ubuntu 16.04.

getfattr -d -m ^ -R -- var/snap/lxd/common/lxd/storage-pools/u1/containers/u2004/rootfs/var/log/journal
# file: var/snap/lxd/common/lxd/storage-pools/u1/containers/u2004/rootfs/var/log/journal
system.posix_acl_access=0s...
system.posix_acl_default=0s...

# file: var/snap/lxd/common/lxd/storage-pools/u1/containers/u2004/rootfs/var/log/journal/5e4ff19e548b4a8ca830426e6086c9ca
system.posix_acl_access=0s...
system.posix_acl_default=0s...

# file: var/snap/lxd/common/lxd/storage-pools/u1/containers/u2004/rootfs/var/log/journal/5e4ff19e548b4a8ca830426e6086c9ca/system.journal
system.posix_acl_access=0s...
system.posix_acl_default=0s...

The copy works fine after deleting var/log/journal.

There are some attributes that copy over OK.

find /home/user/.ramdisk/containers/u2004-e  -exec getfattr -d -m - {} + 2>/dev/null | grep  -v -- '-------------'
# file: home/user/.ramdisk/containers/u2004-e/rootfs/usr/bin/ping6
security.capability=0s...

# file: home/user/.ramdisk/containers/u2004-e/rootfs/usr/bin/ping4
security.capability=0s...

# file: home/user/.ramdisk/containers/u2004-e/rootfs/usr/bin/ping
security.capability=0s...
1 Like
4

I also ran into this on a tmpfs-based CI. Going through an image also seems to be reliable, i.e.

lxc publish u2004 --alias u2004-i --force # note: stops u2004 briefly
lxc launch u2004-i u2004-e -s ram
lxc image delete u2004-i