222
root@server # tar fcz bkup.tar.gz /home/foo/
tar: Removing leading `/' from member names

How can I solve this problem and keep the / on file names ?

3
  • 3
    What exactly is not working as expected?
    – Joachim Isaksson
    Dec 23, 2012 at 12:48
  • 55
    It is not a problem. You do not want leading slashes in a tar archive. Seriously. If you want to extract an archive to your system root, specify -C / when extracting it. Dec 23, 2012 at 15:31
  • I also see tar: Removing leading `/' from hard link targets
    – user598527
    Jun 8, 2023 at 12:17

9 Answers 9

142

If you want to get rid of "Removing leading `/' from member names" being printed to STDERR, but still want to leave off those leading slashes as tar wisely does by default, I saw an excellent solution here by commenter timsoft.

The solution involves using -C option to change directory to the root (/), then specifying the file tree to archive without a leading slash, because now you only need a relative path. This does the same thing as a normal tar create command, but no stripping is needed:

tar fcz bkup.tar.gz -C / home/foo/
5
  • 1
    It won't work with incremental backups. But a good answer.
    – gajdipajti
    Aug 5, 2014 at 7:12
  • 1
    It also doesn't work if you want to tar files denoted by shell-expansion (e.g. tar c -C / home/foo/*), because the shell doesn't know about the changed root. But still a good answer for other cases.
    – Boris
    Apr 15, 2015 at 6:27
  • 3
    -C / doesn't work for me, period. It doesn't prevent the stderr for me.
    – Asclepius
    Aug 10, 2015 at 7:45
  • 4
    @A-B-B make sure the path following -C / is relative.
    – zurfyx
    Dec 31, 2016 at 10:17
  • Will this approach work if a user doesn't have permissions on the root directory?
    – Mladen B.
    Dec 2, 2017 at 7:20
137

Use the --absolute-names or -P option to disable this feature.

tar fczP bkup.tar.gz /home/foo
tar fcz bkup.tar.gz --absolute-names /home/foo
7
  • 90
    This is the correct answer, but be aware, that in most cases, this is not what you want, cause it results in an archive that extracts in complete paths!
    – rubo77
    Nov 21, 2013 at 10:04
  • 20
    Using the -C / option as described in @Marcus' answer will git rid of the STDERR message if that is your primary goal. Dec 28, 2013 at 22:29
  • 3
    Most of the time this is not what a user wants, simply because most of them don't read the manual until they need to (ain't nobody got time for that). So, it would be wise to, at least, expand your answer, warning people not to do this unless they are absolutely sure they understand what's the effect of it. Especially being accepted as an answer.
    – Mladen B.
    Dec 2, 2017 at 7:16
  • @MladenB. tar also removes the leading slash by default when extracting. So even if you use this option when creating the archive, it won't be a problem unless the user also uses it when extracting.
    – Barmar
    Dec 2, 2017 at 9:28
  • Archives with absolute locations are a security risk. Attackers could use such archives to trick users into installing files in critical system locations.
    – A.B.
    Oct 11, 2019 at 8:58
111

That's actually a feature, not a problem. Archives with absolute locations are a security risk. Attackers could use such archives to trick users into installing files in critical system locations.

Yes, you could use -P. But what's wrong with allowing tar to remove the forward slash, and simply requiring the user of the archive to explicitly do the extraction in the root directory? Then they're consciously impacting critical system locations, and can't do it by accident.

2
  • 12
    Sometimes features are problems. I found this thread after setting up a backup script that would email on a non-zero exit status from tar. This particular message was causing tar to exit with a status of 1, which was causing me to receive false email alerts on successful backups, simply because tar was writing this message to STDERR. I fixed this issue by using my own tweaked version of @Marcus's solution: cd /path/to/network/share && tar -cJf scripts.backup.tar.xz -C / home/user/scripts 2>/dev/null || [send an email alert] Dec 14, 2015 at 19:14
  • 1
    I think there are some use cases for using -P - for example, if you're providing some kind of filesystem snapshotting feature in FUSE. Some of the time you may want to untar a snapshot in a specific directory rather than the cwd from the perspective of the user.
    – Byte Lab
    Nov 28, 2016 at 4:11
54

One month late, but I found the most appropriate solution for my case (in a shell script) is to go to the parent directory and execute the command there.

cd /var/www/
tar -czf mysite.gz mysite

Instead of:

tar -czf /var/www/mysite.gz /var/www/mysite
4
  • 18
    Indeed you could have done it using: tar -zcvf mysite.gz -C /var/www/ mysite/ The benefit of this is that you can execute it from any directory Aug 25, 2016 at 15:19
  • 1
    I don't see how this answers the question at all.  It's something different that could be done. … … … Like: Q: How do I get from Los Angeles to New York?  A: Go to San Francisco instead. May 2, 2018 at 20:49
  • I agree with @G-Man . This will result in a tar file with a completely different directory structure. In some cases, that directory structure is actually more appropriate in the first place, but it doesn't answer the question. Nov 7, 2018 at 18:34
  • And you can just do this in a bash script. And at the end of the bash function can just do cd - and that takes you to wherever you were before the script. And can just copy files into the directory via the bash script, before you zip them. Then when you unzip them they just appear in that given directory. Then you can just copy them back to wherever you want in the bash script as well. Its simple this way, works and it avoids the complexity of the tarball command. Comments welcome.
    – john-jones
    Nov 13, 2023 at 11:33
8

This is how I did it by using brute force method: 2>&1 | grep -v "Removing leading".

For example:

tar -cf "$BKUPDIR/${BKUPFILE}.tar" --overwrite --exclude '.*' --one-file-system "$SRCDIR" 2>&1 | grep -v  "Removing leading"
4
  • 5
    The problem with this is it hides the error code. So if you want to check the error code from tar in a bash script, then it won't return 0 on success. Apr 7, 2015 at 15:19
  • @staticx, the error code is 0 regardless.
    – Asclepius
    Aug 10, 2015 at 7:58
  • 1
    @A-B-B My tar command may return 2 on fatal error.
    – Jite
    Nov 2, 2015 at 15:46
  • 1
    @Brian you can use $PIPESTATUS to get the exit code. See unix.stackexchange.com/questions/14270/…
    – simpleuser
    Sep 10, 2016 at 17:13
4

Try to use -C for path only which would prevent compressing with complete paths:

root@server # tar fcz bkup.tar.gz -C /home/ foo/
3

I solved this problem with:

cd /home/foo && tar czf ~/backup.tar.gz .

that way you aren't trying to put absolute paths into the tar archive in the first place. If you want untar it at the root of the file system you just

cd / && tar xzf backupt.tar.gz after transferring it.

2

The path of the archive when specified causes this informational message, you can do the following to resolve it:

tar -zvcf /tmp/mike.tar.gz -P /tmp/mike

or

tar -zvcf mike.tar.gz -P /tmp/mike

or

tar -zvcf mike.tar.gz /tmp/mike

Note: it is not an error, just informational.

-1

its not a feature, its a bug. removing absolute paths creates an unextractable archive if path data gets fooey somehow. tar spits out the error and refuses to extract anything. better to use tardy to filter the path first.

1
  • 6
    Welcome to the site, and thank you for your contribution. What exactly do you mean with "fooey"? Which error have you experienced after extracting a TAR archive that had the leading / removed during creation? To what TAR versions does your comment apply? With GNU tar, I certainly haven't experienced any problems during extraction.
    – AdminBee
    Aug 21, 2020 at 9:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .