snap-installed apps have problems with rclone-mounted Google Drive directories

[David LIndbergh]

I've discovered that both kate and okular (standard editor and PDF viewer for KDE) break when (1) installed via snap and (2) the current directory is a rclone Google Drive remote.

The common factor seems to be installation via snap. If installed via apt, all is well.

--classic doesn't help.

The symptom is that the app exits immediately and "cannot open path of the current working directory: Permission denied" is printed at the terminal. For example:

dave@DARKHELMET:~/data$ /snap/bin/kate pendy.txt
cannot open path of the current working directory: Permission denied

The same happens if attempting to launch from the Dolphin file browser when in such a directory.

In the example above ~/data is such a directory:

dave@DARKHELMET:~$ ll data
lrwxrwxrwx 1 dave dave 27 Mar 20 14:14 data -> /mnt/HookeMyDrive/dave_data/

and:

$ mount | grep rclone
HookeMyDrive{n0BsM}: on /mnt/HookeMyDrive type fuse.rclone (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

I posted on r/rclone about it here: https://www.reddit.com/r/rclone/comments/1bkgprr/google_drive_rclone_kate_editor_problems/

It seems a few other people have run into this and posted about it (without any obvious resolution):

https://stackoverflow.com/questions/58820455/gcloud-cannot-open-path-of-the-current-working-directory-permission-denied

https://forum.rclone.org/t/cannot-launch-vs-code-from-terminal/36215

https://stackoverflow.com/questions/63599162/cannot-open-path-of-the-current-working-directory-permission-denied-when-trying

https://bugs.launchpad.net/snapd/+bug/1973321

Also possibly related:

https://forum.snapcraft.io/t/cannot-open-path-of-the-current-working-directory-permission-denied-bis/28704

https://askubuntu.com/questions/1339502/vs-code-cant-open-directory-on-mounted-folder-cannot-open-path-of-the-current-w

My config:

dave@DARKHELMET:~$ uname -r
6.5.0-25-generic

Operating System: Kubuntu 22.04
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.104.0
Qt Version: 5.15.3
Kernel Version: 6.5.0-25-generic (64-bit)
Graphics Platform: X11
Processors: 16 × Intel® Xeon® W-2145 CPU @ 3.70GHz
Memory: 62.5 GiB of RAM
Graphics Processor: Quadro K620/PCIe/SSE2
Manufacturer: HP
Product Name: HP Z4 G4 Workstation

Here's how I'm mounting remotes with rclone:

_mount_rclone_remote() {
    local mount_point="$1"

    # Expand tilde to the home directory
    mount_point=$(eval echo "$mount_point")

    # Extract the remote name from the last part of the mount point
    local remote_name="${mount_point##*/}"

    # If remote names in rclone.conf have spaces, do not replace them with underscores
    # remote_name="${remote_name// /_}"

    # Check if already mounted
    if mount | grep -q " ${mount_point} "; then
        echo "WARNING: Remote '${remote_name}' is already mounted at ${mount_point}. Nothing done."
        return 0
    fi

    # Create the directory
    mkdir -p "${mount_point}"

    echo Mounting remote \"${remote_name}\" at \"${mount_point}\"

    # Mount using rclone with the extracted remote name
    rclone mount "${remote_name}": "${mount_point}" --daemon \
        --vfs-cache-mode full \
        --vfs-read-ahead 128M \
        --buffer-size 64M \
        --drive-chunk-size 128M \
        --drive-acknowledge-abuse \
        --cache-dir "/home/dave/.cache/rclone/${remote_name}"
}

[David LIndbergh (dave92f1)]

FWIW, I note that snap-installed kate, when *not* in a GDrive directory, works fine UNLESS it's started with strace or ltrace. Then it fails.

This seems to imply some incompatibility between snap and strace/ltrace, independent from the problem rclone/GDrive.

I confess that I'm stumped.