Mv fails in buildx when running on zfs

I’m using buildx to build a docker container.

My docker file has been working fine until I added a second drive to my zfs rpool (not mirrored).

Now when I try to run a ‘mv’ command in my docker file it fails:

#15 0.592 mv: cannot move '/tmp/webp/unzipped/libwebp-1.3.2-linux-x86-64/bin/cwebp' to a subdirectory of itself, '/usr/bin/cwebp'
#15 ERROR: process "/bin/sh -c mv /tmp/webp/unzipped/libwebp-1.3.2-linux-x86-64/bin/cwebp /usr/bin/cwebp" did not complete successfully: exit code: 1
------
 > [10/21] RUN mv /tmp/webp/unzipped/libwebp-1.3.2-linux-x86-64/bin/cwebp /usr/bin/cwebp:

As you can see the target directory isn’t a subdirectory of the source.

Is there some way of fixing this - now that I’ve added the second drive to the rpool the only way to to back is to completely rebuild my system :D.

FYI: I have worked around the problem by changing to using ‘cp’ but I would still understand how to get ‘mv’ working again.

Should I report this as a bug?

zpool status
  pool: bpool
 state: ONLINE
  scan: scrub repaired 0B in 00:00:00 with 0 errors on Sun Jan 14 00:24:01 2024
config:

	NAME         STATE     READ WRITE CKSUM
	bpool        ONLINE       0     0     0
	  nvme0n1p3  ONLINE       0     0     0

errors: No known data errors

  pool: rpool
 state: ONLINE
status: Some supported and requested features are not enabled on the pool.
	The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
	the pool may no longer be accessible by software that does not support
	the features. See zpool-features(7) for details.
  scan: scrub repaired 0B in 00:06:55 with 0 errors on Sun Jan 14 00:30:56 2024
config:

	NAME         STATE     READ WRITE CKSUM
	rpool        ONLINE       0     0     0
	  nvme0n1p4  ONLINE       0     0     0
	  nvme1n1p1  ONLINE       0     0     0

 df -h
Filesystem                                        Size  Used Avail Use% Mounted on
tmpfs                                             3.2G  324M  2.9G  11% /run
rpool/ROOT/ubuntu_c520d1                          512G   20G  492G   4% /
tmpfs                                              16G  244M   16G   2% /dev/shm
tmpfs                                             5.0M  4.0K  5.0M   1% /run/lock
tmpfs                                              16G     0   16G   0% /run/qemu
bpool/BOOT/ubuntu_c520d1                          1.1G  434M  643M  41% /boot
/dev/nvme0n1p1                                    511M   19M  493M   4% /boot/efi
rpool/USERDATA/root_b4334o                        493G  846M  492G   1% /root
rpool/ROOT/ubuntu_c520d1/var/log                  493G  999M  492G   1% /var/log
rpool/ROOT/ubuntu_c520d1/usr/local                493G  581M  492G   1% /usr/local
rpool/ROOT/ubuntu_c520d1/var/lib                  507G   15G  492G   3% /var/lib
rpool/ROOT/ubuntu_c520d1/var/games                492G  128K  492G   1% /var/games
rpool/ROOT/ubuntu_c520d1/srv                      492G  128K  492G   1% /srv
rpool/USERDATA/xxxxx_b4334o                     560G   68G  492G  13% /home/xxxxx
rpool/ROOT/ubuntu_c520d1/var/snap                 492G   13M  492G   1% /var/snap
rpool/ROOT/ubuntu_c520d1/var/mail                 492G  128K  492G   1% /var/mail
rpool/ROOT/ubuntu_c520d1/var/spool                492G  2.4M  492G   1% /var/spool
rpool/ROOT/ubuntu_c520d1/var/www                  492G  128K  492G   1% /var/www
rpool/ROOT/ubuntu_c520d1/var/lib/NetworkManager   492G  256K  492G   1% /var/lib/NetworkManager
rpool/ROOT/ubuntu_c520d1/var/lib/AccountsService  492G  128K  492G   1% /var/lib/AccountsService
rpool/ROOT/ubuntu_c520d1/var/lib/apt              492G   99M  492G   1% /var/lib/apt
rpool/ROOT/ubuntu_c520d1/var/lib/dpkg             492G   76M  492G   1% /var/lib/dpkg
rpool/var/lib/docker                              506G   14G  492G   3% /var/lib/docker
tmpfs                                             3.2G  176K  3.2G   1% /run/user/1000

It indeed looks like a bug. You can raise an issue in the Moby Github repository:

I’ve raised a bug report: