It's, effectively, an apparmor problem, as spotted by Devansh. Still here in 24.04. I personally would not disable the protection completely, evince is heavily used, and you never know...
So what I did is: try to see why it doesn't work. I issued (you need to install apparmor-utils for that) the command to put the specific profile in complain mode, so that it permits the operation but log it on the journal.
sudo aa-complain usr-bin.evince
And yep, it works. The logs (see with journalctl) says (edited for privacy)
audit: type=1400 audit(1724748978.556:314): apparmor="ALLOWED" operation="connect" class="file" profile="/usr/bin/evince" name="/run/user/1001/gvfsd/socket-MqrSttuD" pid=31918 comm="evince" requested_mask="wr" denied_mask="wr" fsuid=1001 ouid=1001
audit: type=1400 audit(1724748978.571:316): apparmor="ALLOWED" operation="open" class="file" profile="/usr/bin/evince" name="/run/user/1001/gvfs/google-drive:host=gmail.com,user=xxx.yyy/0ANkkkkkkJaUk9PVA/llllll
So ok, it was denying the access to the /run/user/... directories.
My solution was to edit (as root) /etc/apparmor.d/local/usr.bin.evince (in principle should be there, empty, and should survive updates, but we'll see) adding
# allow access to google drive and other shared files
owner /run/user//gvfs/* rw,
owner /run/user//gvfsd/* rw,
and then you should reload the profiles:
sudo service apparmor reload
and enforce it again
sudo aa-enforce usr.bin.evince
...and in principle everything works as expected, maintaining the protections AppArmor provides for other files.
Notice that this is probably a configuration bug: I think the directories under `/run/user/UID/ should be permitted by default.