This looks to be a regression to bug 863. This issue exists in: * AIX openssh 6.0.0.6200 (AIX 7.x) * HP-UX OpenSSH_6.2p2+sftpfilecontrol-v1.3-hpn13v12 (HP-UX 11.31) * RHEL OpenSSH_5.3p1 (RHEL 6.4) * Debian openssh 6.7p1-5 (Jessie) REPLICATE: on HOST1 and HOST2 as root: mkdir -p /var/tmp/test/lost+found chmod 777 /var/tmp/test chmod 775 /var/tmp/test/lost+found On HOST1 as non-root user: cd /var/tmp/test for DIR in abc def mno pqr ; do mkdir -p ${DIR} && touch ${DIR}/${RAMDOM} done scp -vpr /var/tmp/test HOST2:/var/tmp/ RESULT: The directory processed immediately after lost+found will not copy across at all, but everything else will. Removing the -p option allows everything to copy, but drops file group/permission bits per user groups/umask as expected.
Just compiled/installed openssh portable on two different Debian GNU/Linux 8.0 (jessie) systems - repeated test. Confirmed this bug still exists in the current code base. $ find sshtest/ -ls 655870 4 drwxrwxrwx 7 root root 4096 May 28 10:05 sshtest/ 655871 4 drwxr-xr-x 2 root root 4096 May 28 10:03 sshtest/lost+found 655878 4 drwxr-x--- 2 brottk brottk 4096 May 28 10:05 sshtest/pqr 655879 0 -rw-r----- 1 brottk brottk 0 May 28 10:05 sshtest/pqr/21417 655874 4 drwxr-x--- 2 brottk brottk 4096 May 28 10:05 sshtest/def 655875 0 -rw-r----- 1 brottk brottk 0 May 28 10:05 sshtest/def/7476 655872 4 drwxr-x--- 2 brottk brottk 4096 May 28 10:05 sshtest/abc 655873 0 -rw-r----- 1 brottk brottk 0 May 28 10:05 sshtest/abc/27521 655876 4 drwxr-x--- 2 brottk brottk 4096 May 28 10:05 sshtest/mno 655877 0 -rw-r----- 1 brottk brottk 0 May 28 10:05 sshtest/mno/28273 $ scp -pr sshtest/ home:./ scp: .//sshtest/lost+found: set times: Operation not permitted 7476 100% 0 0.0KB/s 00:00 27521 100% 0 0.0KB/s 00:00 28273 100% 0 0.0KB/s 00:00 $ ssh home find sshtest -ls 262217 4 drwxrwxrwx 6 root root 4096 May 28 10:21 sshtest 262223 4 drwxr-x--- 2 brottk brottk 4096 May 28 10:05 sshtest/mno 262224 0 -rw-r----- 1 brottk brottk 0 May 28 10:05 sshtest/mno/28273 262218 4 drwxr-xr-x 2 root root 4096 May 28 10:09 sshtest/lost+found 262221 4 drwxr-x--- 2 brottk brottk 4096 May 28 10:05 sshtest/abc 262222 0 -rw-r----- 1 brottk brottk 0 May 28 10:05 sshtest/abc/27521 262219 4 drwxr-x--- 2 brottk brottk 4096 May 28 10:05 sshtest/def 262220 0 -rw-r----- 1 brottk brottk 0 May 28 10:05 sshtest/def/7476
I had a look at this. I don't think it's exactly the same as bug #863; the change for that is still there and I added a regression test for it. I also think it only happens for directories and not files. I added a couple of extra printfs and here's the difference between it working and not: Sink: E File mtime 1433044183 atime 1433044258 Sending file timestamps: T1433044183 0 1433044258 0 -scp: /var/tmp//test/lost+found: set times: Operation not permitted -do_times: response -1 -rsource: skipping +Sink: T1433044183 0 1433044258 0 +do_times: response 0 +Entering directory: D0755 0 pqr +Sink: D0755 0 pqr +Sink: E File mtime 1433044183 atime 1433044196 Sending file timestamps: T1433044183 0 1433044196 0 -Sink: T1433044183 0 1433044258 0 Sink: T1433044183 0 1433044196 0 do_times: response 0 Entering directory: D0755 0 abc @@ -34,9 +35,9 @@ Sink: E File mtime 1433044183 atime 1433044196 Sending file timestamps: T1433044183 0 1433044196 0 +Sink: T1433044183 0 1433044196 0 do_times: response 0 Entering directory: D0755 0 def -Sink: T1433044183 0 1433044196 0 Sink: D0755 0 def Sink: E Sink: E Looks like it's this code in scp.c:rsource() if (pflag) { if (do_times(remout, verbose_mode, statp) < 0) { closedir(dirp); fprintf (stderr, "rsource: skipping\n"); return; } } (void) snprintf(path, sizeof path, "D%04o %d %.1024s\n", (u_int) (statp->st_mode & FILEMODEMASK), 0, last); if (verbose_mode) fprintf(stderr, "Entering directory: %s", path); Not sure what this code is supposed to do, though.
Confirmed it only happens on directories. Repeated test with lost+found converted to a file instead of a directory (and using ${RANDOM} instead of the typo ${RAMDOM} I munged here), and the symptom does not occur.