gcsfuse failed to open /dev/fuse: Permission denied

I'm running the following command inside a container as an ordinary, non-root user

gcsfuse --foreground --debug_fuse --debug_fs --debug_gcs --debug_http my-bucket /data

and it works locally when I start the container with --priviliged and that's fine.

But the same doesn't work on Cloud Run (when using the 2nd generation preview execution environment). I get the following error:

2022-05-13 12:08:41.547 CEST gcs: 2022/05/13 10:08:41.546642 Req 0x1: -> ListObjects("") (46.897367ms): OK
2022-05-13 12:08:41.551 CEST /usr/bin/fusermount: failed to open /dev/fuse: Permission denied
2022-05-13 12:08:41.551 CEST mountWithArgs: mountWithConn: Mount: mount: running /usr/bin/fusermount: exit status 1

All other debug log lines, HTTP, GCS, etc. show everything works.

I create my user like this in my Dockerfile

RUN useradd -lmU joe\
  && mkdir -p /data \
  && chown -R joe:joe /data
USER joe

The docs says that I should run gcsfuse as the user who will be using the file system, not as root, but it doesn't work. Any idea what I'm doing wrong?

For the community in search for an answer to this question :

As per this answer, adding the -file-mode=777 -dir-mode=777 together with gcsfuse command in gcsfuse.sh to enable read/write inside the mounted directory of GCS bucket should be one option but since Kohányi Róbert confirmed that it does not serve the purpose for security reasons. I dig further and I found this really helpful information:

• By default, all inodes in a gcsfuse file system show up as being owned by the UID and GID of the gcsfuse process itself, i.e. the user who mounted the file system. 644 and 755 are the default permissions for all file and directory inodes in a gcsfuse file system. Changing inode mode (using chmod(2) or similar) is unsupported, and changes are silently ignored.

• When you mount your storage bucket using gcsfuse, the fuse kernel layer restricts file system access to the user who mounted the file system. If you like to provide access to other users, you can override this behavior with the allow_other mount option along with the --uid and --gid flags. However, keep in mind that this may have security implications. See here for documentation

• If a person doesn't want to do chmod with 777/ 666 permissions or use allow_other he can try adding himself to a fuse group and change the group to fuse in the /dev/fuse device. I came across this GitHub issue comment which seems fair. Things work locally with the --privileged flag passed to docker run even though the device is owned by root:root. In the GitHub issue comment it's said that they change the group to fuse in the /dev/fuse device. They must execute under root then and that could be a solution for all the users who don’t want to go through 777/ allow_other/ --uid,--gid, 666 hacks.