What does this apt error message ("Download is performed unsandboxed as root...") mean?
I get it after updating in Synaptic Manager
I recently did a clean install of Ubuntu 17.04 from 16.10.
error message:-
W: Download is performed unsandboxed as root as file '/var/cache/apt/archives/partial/samba-libs_2%3a4.5.8+dfsg-0ubuntu0.17.04.1_i386.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) 5 5 Answers
Usually apt uses the user _apt to download packages. In your case _apt doesn't have write permission to either /var/cache/apt/archives/partial/ or an existing file /var/cache/apt/archives/partial/samba-libs_2%3a4.5.8+dfsg-0ubuntu0.17.04.1_i386.deb so it downloaded the file as root.
Make sure /var/cache/apt/archives/partial/ and everything below it are writeable for _apt, e.g. by running
sudo chown -Rv _apt:root /var/cache/apt/archives/partial/
sudo chmod -Rv 700 /var/cache/apt/archives/partial/ 4 tl;dr Just ignore apt related "W: ... _apt ..." warning lines. They're non-fatal, and for the most part you can't fix this, and you'll get the same results with or without the warning.
Even when Florian Diesch's fine answer here is implemented, I'm still getting this warning. I get it when I try and download source, with apt-get source ..., even if I try and download as root, like with sudo or su, (Debian 10.4 and apt 1.8.2.1).
The web is thick with questions about this warning message, with many different suggested solutions. Clearly huge numbers of people have been having trouble with the apt tools ever since it was changed to use _apt for it's sand-boxed, secure operations.
It seems like after this _apt change was made, a whole bunch of things broke that haven't yet been fully fixed.
Let's break this problem down again:
First, apt result lines with a W: prefix are only warnings. A warning being something that is abnormal, but that doesn't stop the program from continuing to operate. (ref: Kusalananda)
As Florian pointed out, "apt uses the user _apt to download packages". It seems this is a case where the user named root simply can't do what the user named _apt can do.
A partial solution, (one you really don't want to use):
You have to make sure the folder your sitting in (i.e. where the source will get put) is owned by _apt:root. So if you $ mkdir temp; sudo chown _apt:root temp; sudo -s and # cd temp; apt-get source ... the warning will not appear.
Of course, you'll then have to put a more reasonable ownership on this base folder once you're done, because it is strange to be owned by _apt:root.
Are the results the same with or without the warning message?
# -- TEST 1: get source into folder owned by user ------------
$ mkdir temp1;
$ cd temp1; sudo apt-get source gnupg2 # gives warning message:
...
W: Download is performed unsandboxed as root as file 'gnupg2_2.2.12-1+deb10u1.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
# -- TEST 2: get source into folder owned by root ------------
$ cd ..; sudo -s
# mkdir temp2;
# cd temp2; apt-get source gnupg2 # gives warning message:
...
W: Download is performed unsandboxed as root as file 'gnupg2_2.2.12-1+deb10u1.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
# -- TEST 3: get source into folder owned by _apt:root -------
# cd ..
# mkdir temp3; chown _apt:root temp3
# cd temp3; apt-get source gnupg2 # no warning message now!
# == COMPARE the results ======================================
$ cd ..
$ sudo diff -r temp1 temp2 # no differences
$ sudo diff -r temp1 temp3 # no differencesSo the results are the same with or without the warning!
I can't help but add, tongue in cheek, that the APT discussed here, does not refer to that most terrible of things: Advanced Persistent Threats.
My previous answer here (was)
...that until now, had fixed this issue for me, but that I can now see, is insufficient:
Fix it with this:
sudo chown -R _apt:root /var/lib/apt/listsSee.
The lists directory itself, not just its contents, needs to have owner _apt. (i.e. Here is one important file branch where default root ownership fails!)
I may have developed this issue when removing lists, and then re-making it with
sudo mkdir lists; apt update, as advised elsewhere.Also this solution may be IN ADDITION TO any other solutions, as I had first tried a bunch of other things.
Debian 10.2 Stretch.
# apt-get --version
apt 1.8.2 (amd64)
Supported modules:
*Ver: Standard .deb
*Pkg: Debian dpkg interface (Priority 30) Pkg: Debian APT solver interface (Priority -1000) Pkg: Debian APT planner interface (Priority -1000) S.L: 'deb' Debian binary tree S.L: 'deb-src' Debian source tree Idx: Debian Source Index Idx: Debian Package Index Idx: Debian Translation Index Idx: Debian dpkg status file Idx: Debian deb file Idx: Debian dsc file Idx: Debian control file Idx: EDSP scenario file Idx: EIPP scenario file 1 I had this problem too on a Debian Stretch (fresh install of a Xen VM), turned out it was a problem with sudo.
Couldn't do any sudo on the machine.
More precisely, the root / directory of the system was in 700 (drwx------). A chmod 755 / fixed it.
Make the file itself readable by the _apt user. eg:
chmod 777 ./pdfsam-visual_2.1.4_amd64.debHave a look at the permissions of the file itself...
$ ls -l ./pdfsam-visual_2.1.4_amd64.deb
-r-------- 1 john john 105659960 Apr 4 11:57 ./pdfsam-visual_2.1.4_amd64.debNow that message again...
N: Download is performed unsandboxed as root as file 'pdfsam-visual_2.1.4_amd64.deb' couldn't be accessed
by user '_apt'. - pkgAcquire::Run (13: Permission denied)The error is because user _apt wants to access the local file. So you only need to grant access to this file. eg:
Now if you remove and install the error will be gone.
sudo apt remove pdfsam-visual
sudo apt install ./pdfsam-visual_2.1.4_amd64.deb The most simple solution here:
Just use the older apt-get:
apt-get --download install xzy
luckily the older apt-get does not have this weird bug.
Apt needs root privileges to do anything, it then drops them for what? Downloading??? While it all of the installs happens with root privileges? Makes absolutely no sense.
Strange note: apt does not have a force flag, NONE, which is very strange. This plus it can't be used for all scripting, so a definite step backward. Why can't we have a better 100% functional replacement of apt-get?