5

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).

  • 1
    It's not just the ownership that wasn't copied, also the timestamps. But you're only showing the toplevel directory. Did this also happen with other files? Did this only happen with directories? Did this only happen with directories that used to belong to user? – Gilles Jul 19 '15 at 21:30
  • Are any of those directories actually subvolumes? If so, then I expect that is likely the issue, as btrfs uses extended attributes to address its atoms. – mikeserv Jul 19 '15 at 21:51
  • I realized that I was an idiot, and I guess this is the normal operation of sudo cp -a if it is aborted. Should I delete this question (I was obviously short sighted) or just leave it as it is? Thanks a lot for everyone for taking the time to look into this. – toraritte Jul 19 '15 at 22:30
2

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
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.