starred/s3fs-fuse

Fork 0

mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 21:35:58 +03:00

[GH-ISSUE #1046] Debian 9 fuse: device not found #576

New issue

Closed

opened 2026-03-04 01:46:52 +03:00 by kerem · 3 comments

kerem commented

2026-03-04 01:46:52 +03:00

Owner

Originally created by @echyam on GitHub (Jun 20, 2019).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1046

Additional Information

Followed https://github.com/s3fs-fuse/s3fs-fuse/wiki/Installation-Notes#debian--ubuntu for Ubuntu 14.04 LTS version. The local build compiled fine, but when I try to mount with
s3fs -o iam_role="s3-access-iam-role" -o url="https://s3-us-west-1.amazonaws.com" bucket-name /mnt
I get

fuse: device not found, try 'modprobe fuse' first
The command '/bin/sh -c sudo s3fs -o iam_role="s3-access-iam-role" -o url="https://s3-us-west-1.amazonaws.com" bucket-name /mnt' returned a non-zero code: 1

Version of s3fs being used (s3fs --version)

latest? I cloned directly from git & built locally

Version of fuse being used (pkg-config --modversion fuse, rpm -qi fuse, dpkg -s fuse)

2.9.7

Kernel information (uname -r)

4.15.0-1035-aws

GNU/Linux Distribution, if applicable (cat /etc/os-release)

Debian GNU/Linux 9 (stretch)

s3fs command line used, if applicable

s3fs -o iam_role="s3-access-iam-role" -o url="https://s3-us-west-1.amazonaws.com" bucket-name /mnt

/etc/fstab entry, if applicable

contents is

# UNCONFIGURED FSTAB FOR BASE SYSTEM

s3fs syslog messages (grep s3fs /var/log/syslog, journalctl | grep s3fs, or s3fs outputs)

no logs

Details about issue

Everything works until the last step of actually mounting

Originally created by @echyam on GitHub (Jun 20, 2019). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1046 ### Additional Information Followed https://github.com/s3fs-fuse/s3fs-fuse/wiki/Installation-Notes#debian--ubuntu for Ubuntu 14.04 LTS version. The local build compiled fine, but when I try to mount with `s3fs -o iam_role="s3-access-iam-role" -o url="https://s3-us-west-1.amazonaws.com" bucket-name /mnt` I get ``` fuse: device not found, try 'modprobe fuse' first The command '/bin/sh -c sudo s3fs -o iam_role="s3-access-iam-role" -o url="https://s3-us-west-1.amazonaws.com" bucket-name /mnt' returned a non-zero code: 1 ``` #### Version of s3fs being used (s3fs --version) latest? I cloned directly from git & built locally #### Version of fuse being used (pkg-config --modversion fuse, rpm -qi fuse, dpkg -s fuse) 2.9.7 #### Kernel information (uname -r) 4.15.0-1035-aws #### GNU/Linux Distribution, if applicable (cat /etc/os-release) Debian GNU/Linux 9 (stretch) #### s3fs command line used, if applicable ``` s3fs -o iam_role="s3-access-iam-role" -o url="https://s3-us-west-1.amazonaws.com" bucket-name /mnt ``` #### /etc/fstab entry, if applicable contents is ``` # UNCONFIGURED FSTAB FOR BASE SYSTEM ``` #### s3fs syslog messages (grep s3fs /var/log/syslog, journalctl | grep s3fs, or s3fs outputs) no logs ### Details about issue Everything works until the last step of actually mounting

kerem closed this issue

2026-03-04 01:46:52 +03:00

kerem commented

2026-03-04 01:46:53 +03:00

Author

Owner

@juliogonzalez commented on GitHub (Jun 20, 2019):

Most probably dumb questions but:

Is fuse module loaded? (lsmod|grep fuse)
Is the fuse device available? (ls -l /dev/fuse)

@juliogonzalez commented on GitHub (Jun 20, 2019): Most probably dumb questions but: 1. Is fuse module loaded? (`lsmod|grep fuse`) 2. Is the fuse device available? (`ls -l /dev/fuse`)

kerem commented

2026-03-04 01:46:53 +03:00

Author

Owner

@echyam commented on GitHub (Jun 20, 2019):

It doesn't have the command lsmod
That's probably it! I got ls: cannot access '/dev/fuse': No such file or directory
How do I make sure it can access the fuse device? (I'm running this in a Dockerfile)

@echyam commented on GitHub (Jun 20, 2019): 1. It doesn't have the command `lsmod` 2. That's probably it! I got `ls: cannot access '/dev/fuse': No such file or directory` How do I make sure it can access the fuse device? (I'm running this in a Dockerfile)

kerem commented

2026-03-04 01:46:53 +03:00

Author

Owner

@juliogonzalez commented on GitHub (Jun 23, 2019):

@echyam then that explains it. Maybe we should ask about that information at the issue template.

So first a:

WARNING

Keep in mind that with the procedure I am going to show, you are breaking the isolation provided by the docker containers: https://lwn.net/Articles/486306/

Which brings us to where we are today: of the 1167 uses of capabilities in C files in the Linux 3.2 source code, 451 of those uses are CAP_SYS_ADMIN. That's rather more than a third of all capability checks. We might wonder if CAP_SYS_ADMIN is overrepresented because of duplications of similar operations in the kernel arch/ trees, or because CAP_SYS_ADMIN is commonly assigned as the capability governing administrative functions on device drivers. However, even after eliminating drivers/ and architectures other than x86, CAP_SYS_ADMIN still accounts for 167—about 30%—of the 552 uses of capabilities. (Fuller details about usage of capabilities in current and earlier kernels can be found here.)

So, on the one hand, the powers granted by CAP_SYS_ADMIN are so numerous and wide ranging that, armed with that capability, there are several avenues of attack by which a rogue process could gain all of the other capabilities. (As has been summarized by Brad Spengler, the ability to be leveraged for full root privileges is a weakness of many existing capabilities; CAP_SYS_ADMIN is just the most egregious example.) On the other hand, so many privileged operations require CAP_SYS_ADMIN that it is the capability most likely to be assigned to a privileged program.

In my case I use it because it's part of my CI for s3fs-fuse RPMs on an isolated machine that doesn't have anything of interest. But I don't recommend doing this on production servers (maybe your sysadmin won't even allow it).

On paper you could request less capabilities (https://opensource.com/business/14/9/security-for-docker), but I never tried to figure out which one is needed).

Procedure

First, you need fuse loaded at the docker host (modprobe fuse, install the packages first if needed) so /dev/fuse can be accesible from the container.

Then, if things didn't change, start the container as I do at: https://github.com/juliogonzalez/s3fs-fuse-rpm/blob/master/ci#L117 (the key parts are --cap-add SYS_ADMIN --device /dev/fuse).

With this, you should be able to mount buckets as long as you root inside the container (again: if things didn't change with newer docker versions).

@juliogonzalez commented on GitHub (Jun 23, 2019): @echyam then that explains it. Maybe we should ask about that information at the issue template. So first a: # WARNING Keep in mind that with the procedure I am going to show, you are breaking the isolation provided by the docker containers: https://lwn.net/Articles/486306/ > Which brings us to where we are today: of the 1167 uses of capabilities in C files in the Linux 3.2 source code, 451 of those uses are CAP_SYS_ADMIN. That's rather more than a third of all capability checks. We might wonder if CAP_SYS_ADMIN is overrepresented because of duplications of similar operations in the kernel arch/ trees, or because CAP_SYS_ADMIN is commonly assigned as the capability governing administrative functions on device drivers. However, even after eliminating drivers/ and architectures other than x86, CAP_SYS_ADMIN still accounts for 167—about 30%—of the 552 uses of capabilities. (Fuller details about usage of capabilities in current and earlier kernels can be found here.) > So, on the one hand, the powers granted by CAP_SYS_ADMIN are so numerous and wide ranging that, armed with that capability, there are several avenues of attack by which a rogue process could gain all of the other capabilities. (As has been summarized by Brad Spengler, the ability to be leveraged for full root privileges is a weakness of many existing capabilities; CAP_SYS_ADMIN is just the most egregious example.) On the other hand, so many privileged operations require CAP_SYS_ADMIN that it is the capability most likely to be assigned to a privileged program. In my case I use it because it's part of my CI for s3fs-fuse RPMs on an isolated machine that doesn't have anything of interest. But I don't recommend doing this on production servers (maybe your sysadmin won't even allow it). On paper you could request less capabilities (https://opensource.com/business/14/9/security-for-docker), but I never tried to figure out which one is needed). # Procedure First, you need `fuse` loaded at the docker host (`modprobe fuse`, install the packages first if needed) so `/dev/fuse` can be accesible from the container. Then, if things didn't change, start the container as I do at: https://github.com/juliogonzalez/s3fs-fuse-rpm/blob/master/ci#L117 (the key parts are `--cap-add SYS_ADMIN --device /dev/fuse`). With this, you should be able to mount buckets as long as you root inside the container (again: if things didn't change with newer docker versions).

kerem referenced this issue

2026-03-04 02:01:01 +03:00

[PR #576] [MERGED] Added option for complementing lack of stat mode #1553