"/dev/fuse: Permission denied" with sshfs, permissions are 0600 instead of 0666 ?

[KnuX]

Hi,

I'm unable to use sshfs without altering "/dev/fuse" permissions. It's not the same issue with WSL1 where fuse was not supported.

I have the following in fresh Ubuntu-18.04 under WSL2:
crw------- 1 root root 10, 229 Sep 11 20:28 /dev/fuse

But in /lib/udev/rules.d/50-udev-default.rules:
KERNEL=="fuse", MODE="0666", OPTIONS+="static_node=fuse

Each reboot, permissions are reset to 0600. After chmoding them, sshfs works like a charm (and it is a very good news !).

[benhillis]

WSL2 does not use udev. We use devtmpfs.

[therealkenc]

/lib/udev/rules.d/50-udev-default.rules

Nothing in your Ubuntu userspace is reading that file, because no systemd-udevd. Landing zone is perennial #994.

WSL2 does not use udev

This is not unlike /dev/tty having the wrong permissions back in the day ref #617. Since /dev/fuse is a static device node, it is going to have to be up to house brand /init to get the permissions right. Like /dev/tty, /dev/fuse can't serve its core purpose if unprivileged users can't write to it. This has not to do with udev per-se, except for the fact privileged systemd-udevd happens to be what sets the permissions on a stock Debian-derived distro.

Suppose the interim work-around would be to set the permissions in .bashrc with sudoers tricks. [edit: or, implied, inviting the whole systemd parade to the party as a big hammer solution.]

[zot]

I just put this at the end of ~/.zlogin as a reminder, it prints out a sudo cmd I can paste and run:

if [ ! -w /dev/fuse ]; then
    echo -e '/dev/fuse is not accessible. Change it with \nsudo chmod 0666 /dev/fuse'
fi

[benhillis]

A change that switches the default permission to 0666 is inbound. I also bumped the default inotify watch limit in the same commit.

[justinkb]

Sorry to comment on an old, closed issue, but are these permissions in any way configurable? If not, any plans to make them configurable? If they are configurable, any plans to document that feature? Furthermore, I noticed the /dev filesystem is shared across all different distros you are running, which seems undesirable. For example, on one of my distros, a certain use case might require /dev/tty have root:tty ownership, while on another distro it might not. Looking at the kernel tree, this setup doesn't seem to be in the kernel code, so I'm guessing this is all in the proprietary Windows implementation of I would guess /init, any chance of opening some of that up or at least making it configurable to some extent (and isolating the /dev filesystem state across distros!)?

[therealkenc]

are these permissions in any way configurable?

That's not a bad question. WSL does not directly support systemd-udevd as of this writing, nor has a WSL-brand /init equivalent. Normally such permissions are configurable via /etc/udev/rules.d/*. Landing zone for that is nominally #994. The standard approach for now is set the permissions in .bashrc with sudoers tricks.

Furthermore, I noticed the /dev filesystem is shared across all different distros you are running

This is presumptively by-design (by fiat), although it would make a fair-game feature request in principle. If you open one, be sure to state the use-case for differing permissions on different distributions. [With no implication that there isn't a cognizant use-case, just that the use-case and a high like count on the feature request goes a long way.] In the alternative, a #994-type approach allows one to mount your own devtmpfs (as opposed to bind mounting the existing one).