77

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
  • 2
    Your running a process that needs root privileges as non-root... Apr 25, 2017 at 15:16
  • 2
    It is known bug 1522675, after long discussion with developers it is fixed. Please wait some hours or one-two days.
    – N0rbert
    Mar 5, 2018 at 7:01
  • This also happens in the ubuntu docker container. You can just ignore the warnings for that case.
    – wisbucky
    Aug 3, 2020 at 18:40
  • Don't "sudo apt source" from unconventional folders unless you meant to. You will get this message from the root folder where you may have been grepping/acking/finding things.
    – mckenzm
    Aug 4, 2021 at 22:44
  • 2
    Why is this still unfixed, almost 5 years later??? I just ran into the issue again, is there a way to just execute ALL OF apt as root? It needs root priviledges already to do anything, why is it dropping permissions for the download? Makes absolutely no sense. Aug 25, 2021 at 6:56

5 Answers 5

58

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
  • 3
    I have this problem while using a mounted folder autside of my vagrant VM, so the mounted folder is always belonging to the user vagrant which cannot be changed. How can I solve this there? maybe just disable the warning, because in my Test VM it is not a problem if apt is run by root
    – rubo77
    Jun 21, 2018 at 17:22
  • 1
    @rubo77 - This fixed that situation for me: github.com/fgrehm/vagrant-cachier/issues/… - setting an explicit owner in synced_folder_opts
    – Henk
    Aug 29, 2018 at 14:13
  • It also helped me to run this command after chowning and chmoding: sudo chmod -Rv 755 /root/.synaptic/tmp. Afterward, no more error!
    – Ev-
    Nov 24, 2018 at 7:54
  • Interesting... in my case I am used to do apt-get install <full-path-to-dot-deb> to install my own packages and I only see this error in 21.10 at the moment. The file is of course protected since I own it. Dec 21, 2021 at 20:55
20

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 differences

So 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/lists

See.


  • 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
  • thanks for your detailed answer, Elliptical view. Really appreciate it. This should be the default accepted answer!
    – xpt
    Jul 19, 2020 at 16:59
6

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.

1
  • Thanks, had this problem in an unprivileged LXC container. The reason was the same as you mentioned: The containers rootfs was set to 750 but needed 755. Apr 17, 2020 at 12:28
1

Make the file itself readable by the _apt user. eg:

chmod 777 ./pdfsam-visual_2.1.4_amd64.deb

Have 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.deb

Now 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
-1

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?

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