[SOLVED] apt-get update fails on mounted iso of stretch DVD

[luvr]

For example, did you use a mount point on a different partition also? If not, then that is not the critical factor, but then can you post some more information on just what you did to get it to fail?

No, everything is one one partition in my case—this Debian system just has a “/” partition, and a swap partition.

From the error messages, it looks nonetheless like some kind of permission issue, involving the "_apt" user, may be at the core of the problem. This is a feature not present in the version of apt that works for me in jessie, so perhaps something about the new "_apt" user needs to be tweaked?

That’s my line of thinking, too. I cannot find much information about this “_apt” user, though, except that it was introduced for tightened security: it allows APT to drop its “root” privileges while downloading from the repositories. I’m puzzled, however, about which authorisations the user does or does not have, and where it gets them from.

Code: Select all

Err:4 file:/media/nick/DebianRepositori/debian-9.0.0-amd64-DVD-1 stretch/main amd64 Packages
  File not found - /media/nick/DebianRepositori/debian-9.0.0-amd64-DVD-1/dists/stretch/main/binary-amd64/Packages (2: No such file or directory)
Reading package lists... Done
N: Download is performed unsandboxed as root as file '/media/nick/DebianRepositori/debian-9.0.0-amd64-DVD-1/dists/stretch/InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
E: Failed to fetch file:/media/nick/DebianRepositori/debian-9.0.0-amd64-DVD-1/dists/stretch/main/binary-amd64/Packages  File not found - /media/nick/DebianRepositori/debian-9.0.0-amd64-DVD-1/dists/stretch/main/binary-amd64/Packages (2: No such file or directory)

I believe the complaints about the “missing” file are misleading—“missing” the point, so to speak, instead of the file. The problem, in my opinion, is not that the file does not exist, but rather that the “_apt” user does not have access to the directory path leading to the file.

I’m thinking of two further tests that could tell us which authorisation the “_apt” user is actually missing. Starting from the working configuration, we could:

• Move the mountpoint to the location that it has in the failing configuration, leaving the image file at its working location. My gut feeling tells me that this should work. If I’m right, then the mountpoint is not the problem, but the location of the image file probably is.
• Leave the mountpoint at its working location, moving the image file to its location in the failing configuration. This is, according to my gut feeling, more likely to fail.

It would be highly awkward if both of these options were successful, because then the “_apt” user would be authorised to access both the mountpoint and the image file, but not simultaneously. Now that would be strange...

Of course, just knowing which authorisation is missing, doesn’t explain why this happens, but at least it will narrow down the search field.

I’m afraid I will have to leave it at that for now. I probably won’t have the opportunity to pick it up again until the weekend.

[gurfle]

Starting from the working configuration, we could:

• Move the mountpoint to the location that it has in the failing configuration, leaving the image file at its working location. My gut feeling tells me that this should work. If I’m right, then the mountpoint is not the problem, but the location of the image file probably is.

In fact I tried this, and it fails.

[*]Leave the mountpoint at its working location, moving the image file to its location in the failing configuration. This is, according to my gut feeling, more likely to fail.[/list]

This one works!

So it's the reverse of what you were guessing: Failure happens when the mount point is not on the root partition, but the location of the image file seems irrelevant.

However, these test really do not seem to reveal much, since it sounds like you got failure with everything in the same partition as root.

When you get a chance, can you post more details of how you got failure. Since yours did not involve a separate partition, knowing what you did will help narrow down the cause of failure even further:

When I follow your post (just replacing “nick” with my own username, “luvr”), I get the same problem as you do.

Does this mean you just created the exact same file and directory structure? In that case I would guess there is something peculiar with the choice of names or their position within the overall directory structure, since, with everything bing located in the same partition in your case, nothing else is different from the successful setups.

[luvr]

So it's the reverse of what you were guessing

Hmmm... My gut feeling was wrong, then, obviously.

Does this mean you just created the exact same file and directory structure?

Exactly: my ‘fstab’ entry looked like this:

Code: Select all

/media/luvr/DebianRepositori/debian-9.0.0-amd64-DVD-1.iso   /media/luvr/DebianRepositori/debian-9.0.0-amd64-DVD-1   udf,iso9660   ro,loop   0   0

and my ‘sources.list’ entry was:

Code: Select all

deb [trusted=yes] file:///media/luvr/DebianRepositori/debian-9.0.0-amd64-DVD-1/ stretch main

(I did leave out the “arch=amd64” option, but whether or not I inserted it, didn’t make a difference.)

In that case I would guess there is something peculiar with the choice of names or their position within the overall directory structure, since, with everything bing located in the same partition in your case, nothing else is different from the successful setups.

Ah! While reading this remark, it suddenly hit me that we had been overlooking one glaringly obvious silly little detail: Both the mountpoint and the image file were in the ‘/media/USERNAME’ directory in the failing case. So, I realised that there must be something special about this location, and I decided to take a closer look:

Code: Select all

$ ls -ld /media/luvr
drwxr-x---+ 2 root root 4096 Jul  4 16:34 /media/luvr

At first sight, the owner of this directory—i.e., the ‘root’ user account—seems to have full access to it; its owning group—i.e., the ‘root’ group of users—has read and execute access; and everyone else is refused access to it. If that were the end of the story, then my own user account—i.e., ‘luvr’—would be unable to enter the location, since it does not belong to the ‘root’ group:

Code: Select all

$ id
uid=1000(luvr) gid=1000(luvr) groups=1000(luvr),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),50(staff),108(netdev),110(lpadmin),113(scanner),118(bluetooth)

But... there is more to the story: The permission bits are followed by a ‘+’ sign—meaning that the filesystem object (i.e., the directory, in this case) has extended Access Control List entries assigned to it:

Code: Select all

$ getfacl --tabular /media/luvr
getfacl: Removing leading '/' from absolute path names
# file: media/luvr
USER   root      rwx
user   luvr      r-x
GROUP  root      ---
mask             r-x
other            ---

So there you have it: The owning user (i.e., the uppercase ‘USER’ entry) is ‘root’ and has full access. My own user account, ‘luvr’, has read and execute access.
The owning group (i.e., the uppercase ‘GROUP’ entry) is ‘root’, and its members (besides the owning user) will be denied access.
The effective rights mask allows read and execute access (limiting access rights of group entries and of named users—does not apply to the owning user or to the ‘other’ entry, however).
Finally, all other users will be denied any access. And THAT explains why the ‘_apt’ user account runs into a brick wall when it attempts to access the location.

To conclude: The ‘/media/USERNAME’ directory is special, in that the owning ‘root’ user account has full access to it, and that the ‘USERNAME’ account has read and execute rights. All other users are denied any access to the location.

[gurfle]

Wow! luvr, your explanation about these subtleties is really great

Access with apt is now possible after doing:

Code: Select all

root@oldlaptop:/home/nick# setfacl -m _apt:rx /media/nick
root@oldlaptop:/home/nick# getfacl --tabular /media/nick
getfacl: Removing leading '/' from absolute path names
# file: media/nick
USER   root      rwx     
user   _apt      r-x     
user   nick      r-x     
GROUP  root      ---     
mask             r-x     
other            ---     

root@oldlaptop:/home/nick# 

Please let me know if this is not an appropriate way to go about accessing debian repository DVD iso files.

The thorough explanations of luvr, not only this last one leading up to the solution, but numerous others along the way of trouble shooting, combined with invaluable patience and persistence, have been extraordinary. I cannot offer enough thanks.

This thread is now marked as solved

[luvr]

Please let me know if this is not an appropriate way to go about accessing debian repository DVD iso files.

I believe this is the right way to do it, if you have the ISO files on an external USB disk, and you want to use the image files without hassle after the USB disk gets automounted. I had begun to think about this issue, too, and I arrived at the same solution that you suggest.

I cannot offer enough thanks.

You're welcome! I found it very instructive to research the issue, and I learned a few details along the way myself.

[luvr]

Access with apt is now possible after doing:
<snip>

Slightly off-topic, but Ubuntu has been displaying “Permission denied” errors implicating the “_apt” user for quite some time now whenever it updates its “adobe-flashplugin” package:

Code: Select all

W: Can't drop privileges for downloading as file '/var/lib/update-notifier/packa
ge-data-downloads/partial/adobe-flashplugin_20170616.1.orig.tar.gz' couldn't be
accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

The solution to your problem here made me realise how to get rid of these errors as well. I just did the following:

Code: Select all

# setfacl -m _apt:rwx /var/lib/update-notifier/package-data-downloads/partial

Then, to verify the result:

Code: Select all

$ getfacl -t /var/lib/update-notifier/package-data-downloads/partial
getfacl: Removing leading '/' from absolute path names
# file: var/lib/update-notifier/package-data-downloads/partial/
USER   root      rwx
user   _apt      rwx
GROUP  root      r-x
mask             rwx
other            r-x

The errors are gone now.