Bug report did not expire due to Chromium task
No response to comment #9 from reporter where fix suggested
** Changed in: chromium-browser (Ubuntu)
Status: Incomplete => Invalid
** Changed in: chromium-browser
Status: New => Invalid
--
You received this bug notification because y
Ok, I have found a fix:
snap connect chromium:removable-media
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1850088
Title:
permission denied when opening a mounted folder i
I have the same bug -
When I want to open a file in /media/user/folder, Chromium refuses.
"Permission denied"
** Also affects: chromium-browser
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to c
@david: this is most likely because your /home/david/ramdisk mount point
is owned by root, not by your user. Try "sudo chown david:david
/home/david/ramdisk", does it fix the problem?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromi
@osomon regarding your question "... ~/server works around the
problem?", I have a tmpfs mount in my $HOME (19.10) and it is
inaccessible to chromium.
/etc/fstab
tmpfs /home/david/ramdisk tmpfs rw,size=2048M 0 0
--
You received this bug notification because you are a member of Desktop
Packages,
It's not possible to install non-classic snap (like chromium) with
--classic switch.
You can get access to /media/$USER/ through removable-media
interface which you have to manually connect to chromium snap.
https://snapcraft.io/docs/removable-media-interface
--
You received this bug notificati
Another fairly simple path to hit this issue is when I mount a drive
from the File Browser. It gets mounted automatically under
/media/$USER/ and isn't accessible in the Snap by default.
I guess installing the snap with --classic would resolve it?
--
You received this bug notification because y
Michael, I understand this is a functional regression as far as you're
concerned, and it's unfortunate. As Jalon Funk pointed out though,
access to dot files and folders inside $HOME is forbidden by snap
confinement, and that is indeed considered a feature (enhancing security
in the general case).
The "proper fix" may never arrive because sandboxing is core feature of
snaps and blocking access to dotfiles is inherent part of sandbox. So
from snap perspective your workflow is invalid.
There are two solutions: adjust your workflow or abandon chromium snap.
It's up to you what you choose.
--
On Tuesday, 29 October 2019 01:23:01 HKT you wrote:
> Snaps don't have access to dotfiles in your home dir (anything in
> ~/.xxx).
>
> The solution for you is to use ~/server instead of ~/.server as mount
> point.
This is clearly a bug, not a feature. I don't know anything about snap, what I
did
Snaps don't have access to dotfiles in your home dir (anything in
~/.xxx).
The solution for you is to use ~/server instead of ~/.server as mount
point.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://b
11 matches
Mail list logo
