Thanks Nathan, I came to the same conclusion as the tickets you
provided, as we were trying to run the snap from a shared nfs mount, but
glad/sad to know that snap was the ultimate problem - sigh. I can now
run the snap directly, without glibc issues so hooray.
I'm now dealing with a different is
Nathan, thanks for the detailed followup. I'm unfortunately not in a
good working state, as I introduced a typo in an environment variable
used to run our functional test harness when I converted to invoking
/snap/bin/chromium with `runuser` instead of a direct invocation form
our vagrant user. T
@Nathan Teodosio:
Just tried running our test harness via runuser and that works with the
edge version of chromium - which is a valid path forward for me,
especially if running directly from the current/user snap path is not
supported.
But I'm still around if you want me to investigate further.
@Nathan Teodosio:
Running either produces the same issue:
```
$ /snap/bin/chromium
cannot open path of the current working directory: Permission denied
$ /snap/bin/chromium --enable-logging=stderr
cannot open path of the current working directory: Permission denied
```
I presume these are issue
Our CI server was manually updated to the edge version of the snap in an
attempt to resolve the issue, but it produces the same error output.
Edit: Our CI server is on Ubuntu 20.04.6 LTS
```
chromium 116.0.5845.4 2527 latest/edge canonical✓ -
```
Glibc version:
```
~$ l
Sure thing, I can provide any information you need.
1. Happened with the latest update to Chromium, has been working fine
for over a year. I use it for functional testing in combination with
selenium and facebook webdriver. Have it installed as a snap, so I
presume it was auto updated, but I do
Same issue for me on Ubuntu 20.04.1 LTS
Same version of chromium snap with the same error output as @Dalik
Output of `snap connections chromium`
```
Interface PlugSlot
Notes
audio-playbackchromium:audio-p
7 matches
Mail list logo
