I don't know if tar(1) is the culprit or an innocent bystander but this is what I am seeing on 10.1-RC1 (r272468 amd64). The archive appears to be written properly prior to generation of the error message. Although the user is permitted to traverse the parent directory and read the -C directory, tar(1) emits the complaint if the parent directory is not also readable. Filesystem is UFS. $ tar -czf dtt.tgz -C /data/tftp/thlan . tar: .: Unable to continue traversing directory tree: Permission denied tar: Error exit delayed from previous errors. $ $ ls -ld /data /data/tftp /data/tftp/thlan drwxr-xr-x 33 root wheel 1024 2 Sep 20:13 /data drwxr-x--x 4 root wheel 512 23 Apr 09:00 /data/tftp drwxr-x--x 3 john wheel 512 23 Apr 10:28 /data/tftp/thlan # chmod o+r /data/tftp $ tar -czf dtt.tgz -C /data/tftp/thlan . $ I haven't played with 10.0 but this behaviour is different to other earlier releases (e.g. 9.3-RELEASE doesn't do this).
Confirmed independently on -stable@ https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080685.html The scenario of traversal-only access to the parent directory is common in a situation where the directory contains per-user subdirectories, and each user has no business knowing about any subdirectory but his own. The archive generated is fine, the user has full permission to the directory being archived, but tar(1) exits with an error status. I regard this regression as a bug.
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
John, can you verify if this issue persists on recent 10.2-PRERELEASE builds?
(In reply to Glen Barber from comment #3) Still a problem on recent 10-STABLE. FreeBSD 10.1-STABLE #0 r284296: Sat Jun 13 06:42:48 AEST 2015 Building r285255 now. Will test and report.
(In reply to Glen Barber from comment #3) Still emits the error on: FreeBSD 10.2-PRERELEASE #0 r285255: Wed Jul 8 12:50:45 AEST 2015 Please note that the cause of this issue was tracked down by Peter Jeremy in the -stable@ thread link included in Commment 1. Thank you for looking at this bug.
This bug still exists in 12-stable.
This should now be fixed (in 10-stable as well as 11-stable and 12-stable) by the MFC of r347990 (see upstream PR #1167).
Assign to committer that resolved. Thank you for the resolution information Andrew