`sudo cp -a` changes ownership to root (instead of preserving the original user)

Question

I was trying to backup some directories and some of the copies made by sudo cp -av resulted in being owned by root while others preserved their attributes. Is this a known issue or am I missing something?

The source (ext4) is a former ubuntu system disk being used externally, directory structure intact but it is only used for storage, not for boot. The username/groupname and uid/gid is the same as in the previous system.

The destination (btrfs) formatted from NTFS, using the 4.1.2 btrfs-progs.

$ sudo cp -av /mnt/src/home/user/thecakeisalie/ /mnt/dest/subvol/

drwx------ 6 user user 4096 Jul 18 09:11 /mnt/src/home/user/thecakeisalie/
drwx------ 3 root root 4096 Jul 18 20:36 /mnt/dest/subvol/thecakeisalie/

  File: ‘/mnt/src/home/user/thecakeisalie/’
  Size: 4096        Blocks: 8          IO Block: 4096   directory
Device: 812h/2066d  Inode: 9044504     Links: 6
Access: (0700/drwx------)  Uid: ( 1000/user)   Gid: ( 1000/user)
Access: 2015-07-18 20:21:08.725414953 -0700
Modify: 2015-07-18 09:11:06.873427304 -0700
Change: 2015-07-18 20:08:34.161737231 -0700
 Birth: -

  File: ‘/mnt/dest/subvol/thecakeisalie/’
  Size: 4096        Blocks: 8          IO Block: 4096   directory
Device: 805h/2053d  Inode: 660098      Links: 3
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-07-18 20:36:23.909377491 -0700
Modify: 2015-07-18 20:36:09.729089386 -0700
Change: 2015-07-18 20:36:09.729089386 -0700
 Birth: -

Testing some other directories under /mnt/src/home/user/thecakeisalie/ resulted in the expected behaviour with ls -l, stat outputs exactly matching.

Some 'well-behaving' directories have been created this afternoon but I tested this on ones that haven't been touched way before I started to use the drive externally and some of them are ok as well.

After backup I chown-ed everything so there is no issue but I am really curious what the cause could be. I googled a lot but I was either not using the right search phrase or this is well-known.

mjturner below had a point so I tried the cp -a commands to my ~/Download dir on the internal system disk (ext4) and the results are the same therefore I don't think it's a btrfs issue.

Last week I fixed up an old laptop where the circumstances were similar: to upgrade Ubuntu 13.10 I had to install Ubuntu 15.04 on another new partition and after boot I did sudo cp -a the entire home from the old system. 13.10 had 2 users (alpha, bravo) and 15.04 had been set up with 1 user (alpha). bravo's entries ended up showing the GID/UID (of course) whereas alpha's looked and worked the same as before. (I have to check whether the GID/UID of old and new alpha where the same).

Some extra info on the current system, uname:
Linux 3.19.0-22-generic #22-Ubuntu SMP Tue Jun 16 17:14:22 UTC 2015 i686

I am going to do a massive clean-up on the source drive (getting rid of the system dirs and moving the main storage dirs to the root) and I'll test again.

In the meantime, are there any other commands that I can use to test the source and destination for differences? It doesn't matter how low I have to dig (I wanted to brush up on C anyway).

Answer 1

I realized that I forgot to mention that I aborted cp -a after checking the destination in another terminal as I was copying 300+ gb of data.

Thanks to Gilles' comment I started testing to see whether it only happens to directories or not. As the tests prove below, basically all files are written as root and the old attributes are applied to the file/directory once it has finished copying.

TEST_1: 3 gb folder and CTRL-C during sudo cp -a: the current file is truncated, left as root and so is the directory.

home/Download# ls -l
total 20
drwx------ 3 root      root       4096 Jul 19 15:11 ./
drwxr-xr-x 3 user user 12288 Jul 19 15:11 ../
drwx------ 2 root      root       4096 Jul 19 15:11 thecakeisalie/

home/Download# cd thecakeisalie/; ls -l
total 16164
drwx------ 2 root      root         4096 Jul 19 15:11 ./
drwx------ 3 root      root         4096 Jul 19 15:11 ../
-rw------- 1 user user 2109623 May 19  2013 file1
-rw------- 1 user user 2520465 May 19  2013 file2
-rw------- 1 root root 393216  Jul 19 15:11 file3

TEST_2: Allow sudo cp -a to finish:

home/Download# ls -l
total 20
drwx------ 3 user user  4096 Jul 19 15:11 ./
drwxr-xr-x 3 user user 12288 Jul 19 15:11 ../
drwx------ 2 user user  4096 Jul 19 15:11 thecakeisalie/

home/Download# cd thecakeisalie/; ls -l
total 16164
drwx------ 3 user user  4096 Jul 19 15:11 ./
drwxr-xr-x 3 user user 12288 Jul 19 15:11 ../
-rw------- 1 user user 2109623 May 19  2013 file1
(...)
-rw------- 1 user user 2520465 May 19  2013 last_file

Answer 2

That looks very odd to me - what you described is definitely not a known issue. I've used cp -a extensively (including to clone entire Linux systems) and the only time I've seen a problem, it was caused by a bug in XFS (which was later fixed).

My guess is that it's a bug in btrfs, which is still undergoing extensive development. Is it reproducible? Can you try copying those same source directories to a new location on your target filesystem and seeing if the permissions are preserved. If it is reproducible, you can file a bug report.