Bug 222899

The SSHFS FAQ says:
-----------------------------
If you don't use udev, you may get this error message:
fusermount: failed to open /dev/fuse: No such device or address
Before loading the fuse kernel module, create the device node manually:
mknod -m 666 /dev/fuse c 10 229
-----------------------------

But SuSE Linux 10.1 is using udev, right?

Load fuse kernel module manually.

Yes it works when I (as root) load the fuse kernel module.

But what is the point of a user space file system, when it requires some action to be taken as root?

If fuse kernel module is not loaded I would expect that it would loaded automatically by ome module probing functionality in the kernel, when the device is accessed. That's pretty much how other kernel modules work, they are loaded automatically on demand, isn't that correct?

Isn't that what all the /etc/modprobe.* files and directories are for?

Do you need any other info?

Add "fuse" to $MODULES_LOADED_ON_BOOT in /etc/sysconfig/kernel file.  Then this module will be automatically loaded at boot time.

I guess you misunderstand about fuse and auto-probing.  There is no direct connection between FUSE and the actual device.  FUSE is a framework and can work even virtually without any devices.  That's why no auto-probing can work for device accessing.

Without udev, it's possible to create /dev/fuse statically and make the kernel triggering fuse at each access.  But, with udev, /dev/fuse is created only after the module is loaded.  A chicken-and-egg problem here.

(In reply to comment #4)

Thanks for the nice explanation.

WRT:
> Add "fuse" to $MODULES_LOADED_ON_BOOT in /etc/sysconfig/kernel file.  Then this module will be automatically loaded at boot time.

If you install the fuse package, it must because you want to use it, right?

So the changes you mention above is most natural to put into the scripts that are run when installing the fuse package.

Nobody (at least not any casual users) will ever install fuse without also wanting to use it (ie. modify /etc/sysconfig/kernel).

Those that will not use fuse (due to footprint reduction, or boot-speed) will either not install fuse at all, or, if they are experts, will be able to do the manual changes in /etc/sysconfig/kernel

Casual users expects that the required configurations needed to use fuse are done automatically when you install the fuse RPM (using YaST).

This comes from an even more general observation than fuse:
When you install a package, you expect that the required system configuration changes necessary to use the package is done automatically when you install the package.

The above expectations also applies to the fuse package.

Well, some features shouldn't be enabled automatically even if a package is installed.  I believe the case of fuse is such one.  (Remember that user-mounted data isn't visible even for root as default.)

I agree that more friendly setup would be needed, but currently it's no real bug.

Please file a feature request for 10.3, instead.  Thanks.

(In reply to comment #6)

I don't understand what you mean by
"user-mounted data isn't visible even for root as default"

Could you explain?

> Please file a feature request for 10.3, instead.  Thanks.

I completely agree that after your explanation in comment 4, what I am requesting is actually a feature request. I will file a FR for SuSE 10.3

Just try to access a directory mounted via sshfs by a normal user.

  % sshfs somewhere ~/xxx

and root cannot access to ~/xxx (with the default setting).

OK, now I understand what you mean by "user-mounted data isn't visible even for root as default"

Then I have comments to
> (Remember that user-mounted data isn't visible even for root as default.)

So?.. How does that imply that 
"some features shouldn't be enabled automatically even if a package is
installed"

My opinion is still: When you are choosing packages, you are actually choosing features, so installing a package without enabling the corresponding feature is pointless.

Anyway in bug 223663 comment 1, Andreas Hanke has proposed a much cleaner solution (than editing /etc/sysconfig/kernel) to the problem, namely to enhance fuse to automatically load the necessary kernel module.

I disagree to enable _every_ feature you installed.  For example, xinetd is disabled as default for a good reason.
The default feature of fuse (root-refusal) is a non-standard behavior and many admin dislike this (while many _users_ love it).  Always enabling it isn't always good for everyone.

(In reply to comment #10)
> I disagree to enable _every_ feature you installed.  For example, xinetd is
> disabled as default for a good reason.
> The default feature of fuse (root-refusal) is a non-standard behavior and many
> admin dislike this (while many _users_ love it).  Always enabling it isn't
> always good for everyone.
> 

This bug has nothing to do with default behaviour of fuse-based filesystems (such as access priviliges to the mounted file system).

The bug is addressing the problem that users cannot mount sshfs (or fuse-based) filesystems at all!

In my comment #9, when I use the term feature I mean "the feature that enables non-privileged users to mount file systems using sshfs" (no matter how sshfs works, as long as works at all), I do not mean any behavioural feautre of sshfs, the feature *is* sshfs itself!

Enabling the feature and installing the package are different issues.  Especially when a program in a package behaves strangely or has any security risk, it shouldn't be enabled as default soon after installation but requires admin's explicit action.  FUSE is one of such packages.

sshfs is a program based on FUSE, and FUSE is deactivated as default.  Thus, that's intentional that user cannot mount via sshfs as default.  It's no bug, as I mentioned.  That's why this bug is closed as WONTFIX.  The only problem is that the setup of FUSE isn't intuitive right now, and should be improved.

Closing as solution has been provided with bug 223663

Jarl