Downloaded file fails to appear in dirs outside of ~/

[Michael Wood]

chromium-browser Version 81.0.4044.129 (Official Build) snap (64-bit)

pkg - 80.0.3987.163-0ubuntu1 500

Steps to reproduce:

1) Have setting "Ask where to save each file before downloading" switched on
2) Go to a webpage and download a file
3) Select a location outside of ~/ , for example /tmp/ (which I have in my location bookmarks)
4) Try to open file or go to "chrome://downloads/" and press "Show in Folder"

What happens:

File appears to download. However the file can't be found by user.

The chrome://downloads/ "Show in Folder" in Chromium does nothing, as does clicking on the file download item. Naturally you try to download the file again and find that it apparently already exists but you still can't see it in the filesystem/file browser/nautilus.

[Olivier Tilloy (osomon)]

The /tmp case is a special case. The snapd security sandbox doesn't allow snaps to share/leak files in the system-wide /tmp, so when you select /tmp in the file save dialog, the file is in fact saved to /tmp/snap.chromium/tmp/, which isn't readable by other snaps (and not even by the current user outside of the sandbox, for that matter).

This does mean that you cannot interact with /tmp as you're used to, and is a conscious security/usability trade-off. There's a discussion about this in bug #1790608.

If you choose to save downloaded files to anywhere else in your home directory, or some place under /mnt or /media (provided the removable-media interface is connected), there should be no problem opening them.

[Michael Wood (x3n)]

If the other bug you linked to is set to 'confirmed', shouldn't this one be too?

Otherwise it is simply blaming the user for not understanding/knowing that chromium-browser's functionality is being broken by the use of Snap.

[Olivier Tilloy (osomon)]

I'm marking this bug as duplicate of the other bug, so that they are merged, and your report contributes to the heat of the other bug.