Giter Site home page Giter Site logo

libfuse's Introduction

libfuse

About

FUSE (Filesystem in Userspace) is an interface for userspace programs to export a filesystem to the Linux kernel. The FUSE project consists of two components: the fuse kernel module (maintained in the regular kernel repositories) and the libfuse userspace library (maintained in this repository). libfuse provides the reference implementation for communicating with the FUSE kernel module.

A FUSE file system is typically implemented as a standalone application that links with libfuse. libfuse provides functions to mount the file system, unmount it, read requests from the kernel, and send responses back. libfuse offers two APIs: a "high-level", synchronous API, and a "low-level" asynchronous API. In both cases, incoming requests from the kernel are passed to the main program using callbacks. When using the high-level API, the callbacks may work with file names and paths instead of inodes, and processing of a request finishes when the callback function returns. When using the low-level API, the callbacks must work with inodes and responses must be sent explicitly using a separate set of API functions.

Development Status

libfuse is shipped by all major Linux distributions and has been in production use across a wide range of systems for many years. However, at present libfuse does not have any active, regular contributors. The current maintainer continues to apply pull requests and makes regular releases, but unfortunately has no capacity to do any development beyond addressing high-impact issues. When reporting bugs, please understand that unless you are including a pull request or are reporting a critical issue, you will probably not get a response. If you are using libfuse, please consider contributing to the project.

Supported Platforms

  • Linux (fully)
  • BSD (mostly/best-effort)
  • For OS-X, please use OSXFUSE

Installation

You can download libfuse from https://github.com/libfuse/libfuse/releases. To build and install, you must use Meson and Ninja. After downloading the tarball and .sig file, verify it using signify:

signify -V -m fuse-X.Y.Z.tar.gz -p fuse-X.Y.pub

The fuse-X.Y.pub file contains the signing key and needs to be obtained from a trustworthy source. Each libfuse release contains the signing key for the release after it in the signify directory, so you only need to manually acquire this file once when you install libfuse for the first time.

After you have validated the tarball, extract it, create a (temporary) build directory and run Meson:

$ tar xzf fuse-X.Y.Z.tar.gz; cd fuse-X.Y.Z
$ mkdir build; cd build
$ meson setup ..

Normally, the default build options will work fine. If you nevertheless want to adjust them, you can do so with the meson configure command:

$ meson configure # list options
$ meson configure -D disable-mtab=true # set an optionq

$ # ensure all meson options are applied to the final build system
$ meson setup --reconfigure ../

To build, test, and install libfuse, you then use Ninja:

$ ninja
$ sudo python3 -m pytest test/
$ sudo ninja install

Running the tests requires the py.test Python module. Instead of running the tests as root, the majority of tests can also be run as a regular user if util/fusermount3 is made setuid root first:

$ sudo chown root:root util/fusermount3
$ sudo chmod 4755 util/fusermount3
$ python3 -m pytest test/

Security implications

The fusermount3 program is installed setuid root. This is done to allow normal users to mount their own filesystem implementations.

To limit the harm that malicious users can do this way, fusermount3 enforces the following limitations:

  • The user can only mount on a mountpoint for which they have write permission

  • The mountpoint must not be a sticky directory which isn't owned by the user (like /tmp usually is)

  • No other user (including root) can access the contents of the mounted filesystem (though this can be relaxed by allowing the use of the allow_other and allow_root mount options in /etc/fuse.conf)

If you intend to use the allow_other mount options, be aware that FUSE has an unresolved security bug: if the default_permissions mount option is not used, the results of the first permission check performed by the file system for a directory entry will be re-used for subsequent accesses as long as the inode of the accessed entry is present in the kernel cache - even if the permissions have since changed, and even if the subsequent access is made by a different user. This is of little concern if the filesystem is accessible only to the mounting user (which has full access to the filesystem anyway), but becomes a security issue when other users are allowed to access the filesystem (since they can exploit this to perform operations on the filesystem that they do not actually have permissions for).

This bug needs to be fixed in the Linux kernel and has been known since 2006 but unfortunately no fix has been applied yet. If you depend on correct permission handling for FUSE file systems, the only workaround is to use default_permissions (which does not currently support ACLs), or to completely disable caching of directory entry attributes.

Building your own filesystem

FUSE comes with several example file systems in the example directory. For example, the passthrough examples mirror the contents of the root directory under the mountpoint. Start from there and adapt the code!

The documentation of the API functions and necessary callbacks is mostly contained in the files include/fuse.h (for the high-level API) and include/fuse_lowlevel.h (for the low-level API). An autogenerated html version of the API is available in the doc/html directory and at http://libfuse.github.io/doxygen.

Getting Help

If you need help, please ask on the [email protected] mailing list (subscribe at https://lists.sourceforge.net/lists/listinfo/fuse-devel).

Please report any bugs on the GitHub issue tracker at https://github.com/libfuse/libfuse/issues.

libfuse's People

Contributors

amir73il avatar anatol avatar asomers avatar billziss-gh avatar bsbernd avatar csabahenk avatar d-hans avatar dagrh avatar dancerj avatar dependabot[bot] avatar fdinoff avatar gaul avatar heretherebedragons avatar infinoid avatar kusumi avatar legezywzh avatar matthiasgoergens avatar michaelforney avatar nikratio avatar nixpanic avatar pnacht avatar przemoc avatar reubenhwk avatar spotrh avatar szmi avatar thejh avatar wdlkmpx avatar winndows avatar yangyun50 avatar zhiqiangliu26 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

libfuse's Issues

Segmentation fault with fuse/sshfs in multi-threaded mode

I'm encountering segmentation faults when using FUSE 2.9.5 with SSHFS 2.5. The stacktrace and Helgrind log suggests that this is race condition in FUSE, rather than SSHFS bug.

Command:

$ sshfs -f -o reconnect -o cache=no -o allow_other -o default_permissions -o ServerAliveCountMax=3 -o ServerAliveInterval=15 REMOTE_HOST:REMOTE_DIR LOCAL_DIR

On another terminal I'm running (this is a reliable way to replicate this bug on my machine):

$ cd LOCAL_DIR
$ for a in `seq 50`
do
    find &
done
wait

After a while sshfs crashes:

*** glibc detected *** sshfs: double free or corruption (out): 0x00007f79c811cf60 ***

Stacktrace:

(gdb) bt
#0  0x00007f7a321ba252 in _int_malloc () from /lib64/libc.so.6
#1  0x00007f7a321bb6b1 in malloc () from /lib64/libc.so.6
#2  0x00007f7a32c30000 in fuse_lib_opendir (req=0x7f79c8120790, ino=45434, llfi=0x7f79ba1fbcc0) at fuse.c:3331
#3  0x00007f7a32c364c9 in do_opendir (req=0x7f79c8000020, nodeid=0, inarg=<value optimized out>) at fuse_lowlevel.c:1375
#4  0x00007f7a32c36ef4 in fuse_ll_process_buf (data=0x612c70, buf=0x7f79ba1fbe60, ch=0x612160) at fuse_lowlevel.c:2442
#5  0x00007f7a32c3387d in fuse_do_work (data=<value optimized out>) at fuse_loop_mt.c:117
#6  0x00007f7a324dc9d1 in start_thread () from /lib64/libpthread.so.0
#7  0x00007f7a322298fd in clone () from /lib64/libc.so.6

I've run sshfs with Helgrind tool from Valgrind and it found something most probably related (full log in attachment).

==17336== Possible data race during read of size 8 at 0x608F1E8 by thread #51
==17336== Locks held: none
==17336==    at 0x4E381FB: get_dirhandle (fuse.c:3316)
==17336==    by 0x4E40915: fuse_lib_releasedir (fuse.c:3520)
==17336==    by 0x4E44074: do_releasedir (fuse_lowlevel.c:1406)
==17336==    by 0x4E45EF3: fuse_ll_process_buf (fuse_lowlevel.c:2442)
==17336==    by 0x4E4287C: fuse_do_work (fuse_loop_mt.c:117)
==17336==    by 0x4C2D0D4: mythread_wrapper (hg_intercepts.c:219)
==17336==    by 0x559D9D0: start_thread (in /lib64/libpthread-2.12.so)
==17336==    by 0xBD5B6FF: ???
==17336== 
==17336== This conflicts with a previous write of size 8 by thread #50
==17336== Locks held: none
==17336==    at 0x4E3F13D: fuse_lib_opendir (fuse.c:3354)
==17336==    by 0x4E454C8: do_opendir (fuse_lowlevel.c:1375)
==17336==    by 0x4E45EF3: fuse_ll_process_buf (fuse_lowlevel.c:2442)
==17336==    by 0x4E4287C: fuse_do_work (fuse_loop_mt.c:117)
==17336==    by 0x4C2D0D4: mythread_wrapper (hg_intercepts.c:219)
==17336==    by 0x559D9D0: start_thread (in /lib64/libpthread-2.12.so)
==17336==    by 0xB35A6FF: ???
==17336== 
==17336== Address 0x608F1E8 is 88 bytes inside a block of size 112 alloc'd
==17336==    at 0x4C279BE: malloc (vg_replace_malloc.c:270)
==17336==    by 0x4E3EFFF: fuse_lib_opendir (fuse.c:3331)
==17336==    by 0x4E454C8: do_opendir (fuse_lowlevel.c:1375)
==17336==    by 0x4E45EF3: fuse_ll_process_buf (fuse_lowlevel.c:2442)
==17336==    by 0x4E4287C: fuse_do_work (fuse_loop_mt.c:117)
==17336==    by 0x4C2D0D4: mythread_wrapper (hg_intercepts.c:219)
==17336==    by 0x559D9D0: start_thread (in /lib64/libpthread-2.12.so)
==17336==    by 0xB35A6FF: ???

The problem does not occur when sshfs is run with -s switch, with multi-threading disabled.

helgrind-1453468851.txt

Publish FUSE documentation generated using Doxygen

Is there any place in the Internet where HTML version of FUSE library documentation can be found? I was using http://fuse.sourceforge.net/doxygen/ which was very convenient, but there is nothing there now. If the project moved to GitHub, how about moving the HTML documentation here? GitHub has a nice mechanism for serving static HTML pages (https://pages.github.com/) which can be used to make the documentation available again -- just create a new repository libfuse/libfuse.github.io and push HTML files there. It would be very convenient to have the documentation for all the official FUSE releases available in this way.

Difference between FUSE_USE_VERSION?

Any documentation about the difference between different FUSE_USE_VERSION? Like what surprising behavior I will have if I bump up this define in my program?

Add clang unit tests

We should run unit tests with clang, in particular with ubsan and address sanitizer.

Memory Leak with libfuse 2.9.4/5

Using Valgrind with libfuse 2.9.4/5 produces the memory leaks below:

==29170== 64 bytes in 1 blocks are still reachable in loss record 433 of 663
==29170== at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
==29170== by 0x513CFFA: fuse_chan_new_common (fuse_session.c:151)
==29170== by 0x51368B0: fuse_kern_chan_new (fuse_kern_chan.c:97)
==29170== by 0x513E7B8: fuse_mount_common (helper.c:238)
==29170== by 0x513EAD6: fuse_setup_common (helper.c:284)
==29170== by 0x513EBF6: fuse_main_common (helper.c:349)
==29170== by 0x403C86: bfs_main_mount (bfs_main.c:625)
==29170== by 0x4040E6: main (bfs_main.c:255)

==29170== 72 bytes in 1 blocks are still reachable in loss record 440 of 663
==29170== at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
==29170== by 0x513D0D2: fuse_session_new (fuse_session.c:36)
==29170== by 0x5137A21: fuse_lowlevel_new_common (fuse_lowlevel.c:2750)
==29170== by 0x5130904: fuse_new_common (fuse.c:4679)
==29170== by 0x513EB00: fuse_setup_common (helper.c:290)
==29170== by 0x513EBF6: fuse_main_common (helper.c:349)
==29170== by 0x403C86: bfs_main_mount (bfs_main.c:625)
==29170== by 0x4040E6: main (bfs_main.c:255)

==29170== 384 bytes in 1 blocks are still reachable in loss record 554 of 663
==29170== at 0x4A057BB: calloc (vg_replace_malloc.c:593)
==29170== by 0x512FA78: fuse_fs_new (fuse.c:4544)
==29170== by 0x513075C: fuse_new_common (fuse.c:4618)
==29170== by 0x513EB00: fuse_setup_common (helper.c:290)
==29170== by 0x513EBF6: fuse_main_common (helper.c:349)
==29170== by 0x403C86: bfs_main_mount (bfs_main.c:625)
==29170== by 0x4040E6: main (bfs_main.c:255)

==29170== 65,536 bytes in 1 blocks are still reachable in loss record 656 of 663
==29170== at 0x4A057BB: calloc (vg_replace_malloc.c:593)
==29170== by 0x512B73A: node_table_init (fuse.c:4559)
==29170== by 0x5130955: fuse_new_common (fuse.c:4698)
==29170== by 0x513EB00: fuse_setup_common (helper.c:290)
==29170== by 0x513EBF6: fuse_main_common (helper.c:349)
==29170== by 0x403C86: bfs_main_mount (bfs_main.c:625)
==29170== by 0x4040E6: main (bfs_main.c:255)

If a fix has already been submitted, please do point me to the fix. Thank you.
Catherine

Kernel deadlock when unlinking

Hi,

We have problem with one software running on sshfs.
Each time when we starting sshfs-folder/SPAdes-3.6.2-Linux/bin/spades.py --test it's hang after few seconds.
We notice that this problem apperas only on linux kernel 3.16.0 and newer and probably any FUSE fs (we tested SSHFS and MooseFS).
When we are running this software on standard hard disk it's working correctly on any kernel.

To repeat error please download:

Our configration:

  • Ubuntu 14.04.1 x86_64
  • kernel 3.19.0-43-generic
  • libfuse 2.9.4

Kernel log:
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116703] INFO: task python:6559 blocked for more than 120 seconds.
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116848] Not tainted 3.19.0-43-generic #49~14.04.1-Ubuntu
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116897] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116958] python D ffff8801754bbd88 0 6559 3837 0x00000000
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116963] ffff8801754bbd88 ffff88007fab0000 0000000000013e80 ffff8801754bbfd8
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116965] 0000000000013e80 ffff880172b24e80 ffff88007fab0000 0000000000000000
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116967] ffff8800b0dd29a8 ffff8800b0dd29ac ffff88007fab0000 00000000ffffffff
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116969] Call Trace:
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116978] [] schedule_preempt_disabled+0x29/0x70
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116981] [] __mutex_lock_slowpath+0x95/0x100
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116983] [] mutex_lock+0x23/0x37
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116987] [] vfs_unlink+0x4d/0x170
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116990] [] do_unlinkat+0x2bb/0x300
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116995] [] ? do_device_not_available+0x33/0x70
Jan 12 11:38:47 blueocean252 kernel: [ 5885.116998] [] SyS_unlink+0x16/0x20
Jan 12 11:38:47 blueocean252 kernel: [ 5885.117000] [] system_call_fastpath+0x16/0x1b

Consider versioning all symbols

Latest fuse version fails to build when using the gold linker.
There is a tentative patch that has been going around for a while in various websites and repos:

I have generated a patch against fuse-2.9.5 and verified that fuse compiles and tests fine (both with ld.gold and ld.bfd):
https://github.com/fsvm88/gentoo-portage_etc/blob/master/patches/sys-fs/fuse/fuse-gold.patch

Can you please update it if needed and merge it?
Thank you

lookup() not called when readdir() returns inode with lowest 32bits set to 0

Hi,
I am experiencing strange behavior when readdir returns entry which has lowest 32bits set to zero.

Not working inode number

  • 3659174697238528 - 1101000010100000000000000000000000000000000000000000b

Application Log

GoodDataFS::readdir() - Reading inode 3659174697238528 - Inode { project: 13, category: 0, item: 0, reserved: 0 }
GoodDataFS::readdir() - Adding inode 3670169813516288 - Inode { project: 13, category: 10, item: 0, reserved: 0 }, project 12, path metadata

Working inode number

  • 3670169813516289 - 1101000010100000000000000000000000000000000000000001b

Application Log

GoodDataFS::readdir() - Reading inode 3659174697238528 - Inode { project: 13, category: 0, item: 0, reserved: 0 }
GoodDataFS::readdir() - Adding inode 3670169813516289 - Inode { project: 13, category: 10, item: 0, reserved: 1 }, project 12, path metadata
GoodDataFS::lookup() - Reading parent 3659174697238528 - Inode { project: 13, category: 0, item: 0, reserved: 0 }, path "metadata"

Environment

  • Mac OS X El capitan 64 bit

node id format

Bits Offset Description Limit
16 48 Project ID 65535 projects
8 40 Category ID 256 categories
32 8 Item ID 4294967295 items
8 0 Reserved 256 reserves ;-)

For more info see documentation

PS: I tried to compile same code on linux and it works without any problems.

Am I missing something? Am I doing something wrong? I tried to search if there are any requirements for inode format but I found nothing.

Add basic unit tests

We should provide some tests that check for at least basic functionality. Probably mounting each of the examples and running test/test.c is a good start.

Support blocking umount

fusermount -u should be able to block until the FUSE process terminates or somehow signals that it is done. This will need support from the kernel module. Similar to allow-other and allow-root, this feature will need to be explicitly enabled so that unprivileged users aren't able to block root from unmounting a file system (and thereby e.g. prevent a system reboot).

parent exit() vs. child setsid() race

Forwarding from http://bugs.launchpad.net/bugs/1558967
== Comment: #21 - Hendrik Brueckner - 2016-03-16 06:44:09 ==
Package: libfuse2
Version: 2.9.4-1ubuntu2

The cmsfs-fuse program is used to transfer files from a CMSFS dasd (on z/VM) to Linux. The procedure is to mount, copy files, umount. All commands are issued from within an application over an SSH connection.

The problem is that the copy intermittently fails with "Transport endpoint is not connected". The procedure is as follows:

#mount cmsfs
sudo /usr/bin/cmsfs-fuse /dev/dasdb /usr/wave/wavedisk

copy file

/bin/cp -f /usr/wave/wavedisk/WAVEDATA.SCRIPT /usr/wave/wavedata
/bin/cp: cannot stat '/usr/wave/wavedisk/WAVEDATA.SCRIPT': Transport endpoint is not connected
#umount
umount /usr/wave/wavedisk

Because the application uses JSCH to issue the commands, I worked on a non-Java reproducer using SSH.

The problem can be easily re-created with ssh as follows:

root@r3559004:# ssh -t root@localhost "cmsfs-fuse /dev/disk/by-path/ccw-0.0.0190 /CMSFS"
Connection to localhost closed.
root@r3559004:
# ls /CMSFS
ls: cannot access '/CMSFS': Transport endpoint is not connected

Problem analysis will follow but not that is not specific to cmsfs-fuse; the problem might also occur with other fuse file systems that are mounted through an SSH connection.

== Comment: #23 - Hendrik Brueckner - 2016-03-16 07:07:30 ==
After debugging and some code review on the libfuse library, I think that
we identified the root cause. As suggested, the problem is not related
to cmsfs-fuse directly.

The cmsfs-fuse main program calls into the libfuse library() using the
fuse_main() function. The fuse_main() function later calls the
fuse_daemonize() to fork the daemon process to handle the fuse file
system I/O.

The fuse_daemonize() look at follows:

180 int fuse_daemonize(int foreground)
181 {
182 if (!foreground) {
183 int nullfd;
184
185 /*
186 * demonize current process by forking it and killing the
187 * parent. This makes current process as a child of 'init'.
188 */
189 switch(fork()) {
190 case -1:
191 perror("fuse_daemonize: fork");
192 return -1;
193 case 0:
194 break;
195 default:
196 _exit(0);
197 }
198
199 if (setsid() == -1) {
200 perror("fuse_daemonize: setsid");
201 return -1;
202 }
203
204 (void) chdir("/");
205
206 nullfd = open("/dev/null", O_RDWR, 0);
207 if (nullfd != -1) {
208 (void) dup2(nullfd, 0);
209 (void) dup2(nullfd, 1);
210 (void) dup2(nullfd, 2);
211 if (nullfd > 2)
212 close(nullfd);
213 }
214 }
215 return 0;
216 }

The fuse_daemonize() function calls fork() as usual. The child proceeds with setsid() and then redirecting its file descriptors to /dev/null etc. The parent process, simply exits.

The child's functions and the parent's exit creates a subtle race. This is seen with an SSH connection. The SSH command "ssh -t root@localhost "cmsfs-fuse /dev/disk/by-path/ccw-0.0.0190 /CMSFS" calls the cmsfs-fuse on an allocated pseudo-terminal device (-t option).

If the parent exits, the SSH command receives that its command has been executed and closes the connection, that means, it closes the master side of the pseudo-terminal. This causes a HUP signal being sent to the process group on the pseudo-terminal. The child might not have completed the setsid() call and hence becomes terminated. Note that fuse sets up its signal handler later after fuse_daemonize() has complete.

Even if the child has the chance to disassociate from it's parent process group to become it's own process group with setsid(), the child still has the pseudo-terminal opened as stdin, stdout, and stderr. So the pseudo-terminal still behave as controlling terminal and might cause a SIGHUP to be issued at closing the the master side.

To solve the problem, the parent has to wait until the child (the fuse daemon process) has completed its processing, that means, has become its own process group with setsid() and closed any file descriptors pointing to the pseudo-terminal.

For example, using a pipe as follows could solve the problem:

The parent waits on the pipe, then exits:

read(waiter[0], &completed, sizeof(completed));
_exit(0);

The child signals its completion (after redirecting its file descriptors) with:
completed = 1;
write(waiter[1], &completed, sizeof(completed));

== Comment: #24 - Gerald Schaefer - 2016-03-16 08:18:20 ==
The race can also be triggered w/o ssh, by using "setsid -c", and I can also reproduce it w/o cmsfs-fuse but with sshfs:

root@s3545003:# setsid -c sshfs geraldsc@tuxmaker: sshfs/
root@s3545003:
# ls sshfs
ls: cannot access 'sshfs': Transport endpoint is not connected

Pass fuse_file_info in chown, chmod, utimensat, etc

Hi,

I would like to get the file handle that was set in open when fchown, fchmod, and futimens are called.
This is necessary to distinguish between syscalls, such as, chown and fchown, which make a difference
when the underlying implementantion is inode-based and not path-based.

Is it possible to create new FUSE handlers fchown, fchmod, futimens, that receive the fuse_file_info
structure, which contains the file handle created in open?

Thanks,
Jose

Avoid use of reserved identifiers

According to the C standard section 17.6.4.3.2 ("Global Names"):

Certain sets of names and function signatures are always reserved to the implementation:

  • Each name that contains a double underscore __ or begins with an underscore followed by an uppercase letter (2.12) is reserved to the implementation for any use.
  • Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

Below is a list of defines which violate this section (by using reserved identifiers):

include/fuse_common.h:#define _FUSE_COMMON_H_
include/fuse_opt.h:#define _FUSE_OPT_H_
include/fuse_lowlevel.h:#define _FUSE_LOWLEVEL_H_
include/cuse_lowlevel.h:#define _CUSE_LOWLEVEL_H_
include/fuse.h:#define _FUSE_H_
include/fuse_kernel.h:#define _LINUX_FUSE_H

Simply removing the leading _ corrects this issue.

Error specifying subtype: "/bin/sh: <subtype>: command not found"

When specifying the subtype to the mount command with e.g. mount -t fuse.bindfs, I get the following error:

/bin/sh: bindfs: command not found

It occurs on this line in mount.fuse:

execl("/bin/sh", "/bin/sh", "-c", command, NULL);

If I turn the subtype to a full path of an executable, it works, e.g. mount -t fuse./path/to/bindfs. But obviously only if the path itself does not contain any dots.

I have two questions:

  1. Why is it running /bin/sh/ instead of running the executable directly?
  2. Why not use execvp, which searches in the PATH variable for the executable. This way it would find bindfs in my case.

Disclaimer: I am using NixOS, which does weird things with executable paths. This is probably why the bug has not occurred in other operating systems

Release versioning

Hey there, any particular reason the version tags are fuse_X_Y_Z instead of the more typical X.Y.Z or vX.Y.Z?

It has required that we write a custom regex to detect version increments for packaging in FreeBSD.

libfuse can't work with libevent

Hi,
libfuse provided an API of fuse_chan_fd to access the field of "fd" defined in fuse_chan, based on fuse_chan_fd, libfuse can work with libevent well, but in the latest codes, the API, fuse_chan_fd, has been removed.

Thanks
hunting

Pass request context to all handlers

I don't see any reason why we need a special function to access the request context, it should simply be passed to all handlers. This avoids any trickery with thread-local variables.

I suspect the function was introduced in order to not break the API. With FUSE 3, this is no longer a concern.

Cannot compile in Amazon Linux AMI release 2016.03 (EC2)

I think that configure test are failing since I get:

Please install util-linux version 2.18 or later which supports

But I have 2.23 installed. See this output:

# yum install util-linux
Loaded plugins: priorities, protectbase, update-motd, upgrade-helper
amzn-main/latest                                                                                                                                                                                                  | 2.1 kB     00:00     
amzn-updates/latest                                                                                                                                                                                               | 2.3 kB     00:00     
0 packages excluded due to repository protections
Package util-linux-2.23.2-22.26.amzn1.x86_64 already installed and latest version
Nothing to do

# umount -h

Usage:
 umount [-hV]
 umount -a [options]
 umount [options] <source> | <directory>

Options:
 -a, --all               unmount all filesystems
 -A, --all-targets       unmount all mountpoins for the given device
                         in the current namespace
 -c, --no-canonicalize   don't canonicalize paths
 -d, --detach-loop       if mounted loop device, also free this loop device
     --fake              dry run; skip the umount(2) syscall
 -f, --force             force unmount (in case of an unreachable NFS system)
 -i, --internal-only     don't call the umount.<type> helpers
 -n, --no-mtab           don't write to /etc/mtab
 -l, --lazy              detach the filesystem now, and cleanup all later
 -O, --test-opts <list>  limit the set of filesystems (use with -a)
 -R, --recursive         recursively unmount a target with all its children
 -r, --read-only         In case unmounting fails, try to remount read-only
 -t, --types <list>      limit the set of filesystem types
 -v, --verbose           say what is being done

 -h, --help     display this help and exit
 -V, --version  output version information and exit

For more details see umount(8).


# ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking how to print strings... printf
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc option to accept ISO C99... -std=gnu99
checking for gcc -std=gnu99 option to accept ISO Standard C... (cached) -std=gnu99
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking whether gcc -std=gnu99 and cc understand -c and -o together... yes
checking for fork... yes
checking for setxattr... yes
checking for fdatasync... yes
checking for splice... yes
checking for vmsplice... yes
checking for utimensat... yes
checking for pipe2... yes
checking for posix_fallocate... yes
checking for fstatat... yes
checking for openat... yes
checking for readlinkat... yes
checking for struct stat.st_atim... yes
checking for struct stat.st_atimespec... no
checking for library containing dlopen... -ldl
checking for library containing clock_gettime... none required
checking for ulockmgr_op in -lulockmgr... no
checking for ld used by GCC... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for working iconv... yes
checking for iconv declaration... 
         extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
configure: MOUNT_FUSE_PATH env var not set, using default /sbin
configure: UDEV_RULES_PATH env var not set, using default NONE/lib/udev/rules.d
configure: INIT_D_PATH env var not set, using default /etc/init.d
checking if umount supports --fake --no-canonicalize... 
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating fuse3.pc
config.status: creating Makefile
config.status: creating lib/Makefile
config.status: creating util/Makefile
config.status: creating example/Makefile
config.status: creating include/Makefile
config.status: creating doc/Makefile
config.status: creating test/Makefile
config.status: creating include/config.h
config.status: include/config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands
configure: WARNING:
******************************************************************
* Please install util-linux version 2.18 or later which supports *
* --fake and --no-canonicalize options in mount and umount       *
******************************************************************

Feature Request: Canonical example of "Proxy Overlay Filesystem"

Hi!

Could you recommend best example (preferably for C/C++ or Go), of Overlay Filesystem, that would be close as possible to just "proxying" underlaying filesystem?
Otherwise, consider adding such as one another example in examples directory?

In such, each call made to it would go through it and reach underlying filesystem unchanged and response came back.
(Such example could log operations, or do some measurements).
Such example would be great to follow to make own instrumentations (like benchmarking or things like: http://unix.stackexchange.com/q/283149/9689 fast ).

Thanks in advance and best regards,
Grzegorz Wierzowiecki

Look into dropping channel abstraction

I believe there was a plan to drop struct fuse_chan entirely in FUSE 3. However, it's still present at least in fuse_lowlevel.h. We should check if this was intentional or not, and maybe remove this abstraction completely before we release FUSE3.

Cannot build example/ because 'config.h'

When I clone GitHub repo(master branch) and build example directory. like on 'hello.c'

gcc -Wall hello.c `pkg-config fuse --cflags --libs` -o hello

But I failed. So I downloaded release v2.9.5 and I succeeded build.

I think that this repo missed 'config.h'.

writeback_cache performance drops

Hi,
I am experimenting with Kernel 4.5.0-1(EL7) and the master branch of today of libfuse and the writeback cache feature.

I observe that the FUSE fs stalls for some time.

[root@fuse3 example]# ./fusexmp_fh -o writeback_cache /mnt
[root@fuse3 example]# dd if=/dev/zero of=/mnt/tmp/wb bs=1M count=40
40+0 records in
40+0 records out
41943040 bytes (42 MB) copied, 0,41428 s, 101 MB/s
[root@fuse3 example]# dd if=/dev/zero of=/mnt/tmp/wb bs=1M count=40
40+0 records in
40+0 records out
41943040 bytes (42 MB) copied, 4,22575 s, 9,9 MB/s
[root@fuse3 example]# dd if=/dev/zero of=/mnt/tmp/wb bs=1M count=40
40+0 records in
40+0 records out
41943040 bytes (42 MB) copied, 0,366669 s, 114 MB/s
[root@fuse3 example]# dd if=/dev/zero of=/mnt/tmp/wb bs=1M count=40
40+0 records in
40+0 records out
41943040 bytes (42 MB) copied, 33,6292 s, 1,2 MB/s

Enabling the low-level debug when using it with my own FUSE module (where it behaves the same) i can see, that everything in user space runs perfectly fine and after sending a response to flush there are no new requests coming for some time.

I see the same behaviour with Kernel 4.4.0.

Not sure it is important. The host is a VM.

Thanks Andreas.

sshfs and fuse can run properly on AIX 6.1??

I have tried compile it on aix 6.1 just to test and got some errors.
Do you think sshfs/fuse can work fine on aix 6.1?
./configure works fine, however I have error below during make -j8

: make -j8

Making all in include
make all-am
Target "all-am" is up to date.
Making all in lib
CC fuse.lo
CC fuse_kern_chan.lo
CC fuse_loop.lo
CC fuse_loop_mt.lo
CC fuse_lowlevel.lo
CC fuse_mt.lo
CC fuse_opt.lo
CC fuse_session.lo
CC fuse_signals.lo
CC buffer.lo
CC cuse_lowlevel.lo
CC helper.lo
CC modules/subdir.lo
CC modules/iconv.lo
CC mount.lo
CC mount_util.lo
CC ulockmgr.lo
fuse.c: In function 'convert_statfs_old':
fuse.c:1535:27: error: 'struct statfs' has no member named 'f_namelen'
stbuf->f_namemax = oldbuf->f_namelen;
^
fuse.c: In function 'fuse_fs_utimens':
fuse.c:2154:5: warning: format '%li' expects argument of type 'long int', but argument 4 has type 'time_t' [-Wformat=]
tv[1].tv_sec, tv[1].tv_nsec);
^
fuse.c:2154:5: warning: format '%li' expects argument of type 'long int', but argument 6 has type 'time_t' [-Wformat=]
fuse.c:2162:5: warning: format '%li' expects argument of type 'long int', but argument 4 has type 'time_t' [-Wformat=]
tv[0].tv_sec, tv[1].tv_sec);
^
fuse.c:2162:5: warning: format '%li' expects argument of type 'long int', but argument 5 has type 'time_t' [-Wformat=]
fuse.c: In function 'locks_insert':
fuse.c:3745:10: warning: comparison is always true due to limited range of data type [-Wtype-limits]
lock->end != OFFSET_MAX) {
^
fuse.c: In function 'lock_to_flock':
fuse.c:3827:8: warning: comparison is always false due to limited range of data type [-Wtype-limits](lock->end == OFFSET_MAX) ? 0 : lock->end - lock->start + 1;
^
Assembler:
/tmp//ccBPTgBf.s: line 562: Invalid relocation type: .
/tmp//ccBPTgBf.s: line 562: invalid opcode or pseudo-op
buffer.c: In function 'fuse_buf_splice':
buffer.c:171:19: error: 'SPLICE_F_MOVE' undeclared (first use in this function)
splice_flags |= SPLICE_F_MOVE;
^
buffer.c:171:19: note: each undeclared identifier is reported only once for each function it appears in
buffer.c:173:19: error: 'SPLICE_F_NONBLOCK' undeclared (first use in this function)
splice_flags |= SPLICE_F_NONBLOCK;
^
buffer.c:185:3: warning: implicit declaration of function 'splice' [-Wimplicit-function-declaration]
res = splice(src->fd, srcpos, dst->fd, dstpos, len,
^
make: 1254-004 The error code from the last command is mount.c:127:23: fatal error: sys/mount.h: No such file or directory
#include <sys/mount.h>
^
compilation terminated.
.

Stop.
make: 1254-004 The error code from the last command is 1.

Stop.

: modules/iconv.c: In function 'iconv_convpath':

modules/iconv.c:69:8: warning: passing argument 2 of 'libiconv' from incompatible pointer type [enabled by default]
&pathlen, &p, &plen);
^
In file included from modules/iconv.c:17:0:
/opt/freeware/include/iconv.h:83:15: note: expected 'const char *' but argument is of type 'char *'
extern size_t iconv (iconv_t cd, const char* * inbuf, size_t inbytesleft, char * outbuf, size_t *outbytesleft);
^
fuse_lowlevel.c: In function 'fuse_ll_receive_buf':
fuse_lowlevel.c:2612:2: warning: implicit declaration of function 'splice' [-Wimplicit-function-declaration]
res = splice(fuse_chan_fd(ch), NULL, llp->pipe[1], NULL, bufsize, 0);
^
fuse_lowlevel.c: In function 'fuse_req_getgroups':
fuse_lowlevel.c:2839:35: warning: unused parameter 'req' [-Wunused-parameter]
int fuse_req_getgroups(fuse_req_t req, int size, gid_t list[])
^
fuse_lowlevel.c:2839:44: warning: unused parameter 'size' [-Wunused-parameter]
int fuse_req_getgroups(fuse_req_t req, int size, gid_t list[])
^
fuse_lowlevel.c:2839:56: warning: unused parameter 'list' [-Wunused-parameter]
int fuse_req_getgroups(fuse_req_t req, int size, gid_t list[])
^
fuse_lowlevel.c: In function 'convert_statfs_compat':
fuse_lowlevel.c:2866:28: error: 'const struct statfs' has no member named 'f_namelen'
buf->f_namemax = compatbuf->f_namelen;
^
mount_util.c:25:23: fatal error: sys/mount.h: No such file or directory
#include <sys/mount.h>
^
compilation terminated.
Assembler:
/tmp//cc5o0lQx.s: line 573: Invalid relocation type: .
/tmp//cc5o0lQx.s: line 573: invalid opcode or pseudo-op
/tmp//cc5o0lQx.s: line 574: Invalid relocation type: FUSE_.
/tmp//cc5o0lQx.s: line 574: invalid opcode or pseudo-op
/tmp//cc5o0lQx.s: line 574: Error In Syntax
/tmp//cc5o0lQx.s: line 575: Invalid relocation type: .
/tmp//cc5o0lQx.s: line 575: invalid opcode or pseudo-op
/tmp//cc5o0lQx.s: line 576: Invalid relocation type: .
/tmp//cc5o0lQx.s: line 576: invalid opcode or pseudo-op
/tmp//cc5o0lQx.s: line 577: Invalid relocation type: FUSE_.
/tmp//cc5o0lQx.s: line 577: invalid opcode or pseudo-op
/tmp//cc5o0lQx.s: line 577: Error In Syntax
/tmp//cc5o0lQx.s: line 578: Invalid relocation type: FUSE_.
/tmp//cc5o0lQx.s: line 578: invalid opcode or pseudo-op
/tmp//cc5o0lQx.s: line 578: Error In Syntax
/tmp//cc5o0lQx.s: line 579: Invalid relocation type: FUSE_.
/tmp//cc5o0lQx.s: line 579: invalid opcode or pseudo-op
/tmp//cc5o0lQx.s: line 579: Error In Syntax
/tmp//cc5o0lQx.s: line 580: Invalid relocation type: FUSE_.
/tmp//cc5o0lQx.s: line 580: invalid opcode or pseudo-op
/tmp//cc5o0lQx.s: line 580: Error In Syntax
/tmp//cc5o0lQx.s: line 581: Invalid relocation type: FUSE_.
/tmp//cc5o0lQx.s: line 581: invalid opcode or pseudo-op
/tmp//cc5o0lQx.s: line 581: Error In Syntax
Assembler:
/tmp//ccDwzKNl.s: line 516: Invalid relocation type: FUSE_.
/tmp//ccDwzKNl.s: line 516: invalid opcode or pseudo-op
/tmp//ccDwzKNl.s: line 516: Error In Syntax
Assembler:
/tmp//ccvGpP5X.s: line 568: Invalid relocation type: FUSE_.
/tmp//ccvGpP5X.s: line 568: invalid opcode or pseudo-op
/tmp//ccvGpP5X.s: line 568: Error In Syntax

Auto unmount stale FUSE mount before mounting at start-up

I see libfuse has an -o auto_unmount option. That's great. But what about the case where, at start-up, the mount point is still mounted stale? It might be good to have an option to auto unmount the stale mount, before remounting, rather than failing with a "bad mount point : Transport endpoint is not connected" error.

I looked up the old mailing list messages about the auto-unmount idea several years ago. Someone pointed out that some might want the stale mount to persist so programs accessing it (such as rsync) get an error rather than just an empty directory. That sounds fair enough. Si in that case, -o auto_unmount wouldn't be used, but then it would be nice to clean up the stale mount next time the program is run.

Is that a reasonable feature idea, or is there a better way to handle that scenario?

fgetattr() Not Being Called By fstat()

Hi,

If I call fstat() on a file within a fuse file system I only see an fgetattr() when the file is first created by the open call. If I call fstat() on an existing file, it uses getattr() instead.

I guess this isn't a big problem for most file systems, but getattr() is a very expensive operation on mine due to the path manipulation (whereas with fgetattr() the supplied fd can be used directly). Compounding this, some network file system daemons call fstat() after every write call (I assume to check that the file size is increasing), which kills the write speed.

I originally found this using a custom libfuse build based on 2.9.7, but I've also replicated it in the build shipped with Ubuntu 14 Trusty (I believe 2.9.2). I've also replicated it on the Ubuntu kernel (based on 3.19) and a custom gentoo kernel (based on 4.4 with some grsecurity mixed in).

Here's pseudo code for the replication:

fd = open(<path>, O_RDWR | O_CREAT):

for(iter = 0; iter < 3; iter++) {
    fstat(fd, <stbuf>);
    sleep(2);
}

close(fd);

Which results in these calls in fuse:

# Test run for first time, file created - We see one fgetattr then only getattrs #
getattr called! ('/test', 0x7f3ddbdcac20)
[f]getattr called! ('/test', 0x7f3ddb5c9be0, 0x7f3ddb5c9d10)
getattr called! ('/test', 0x7f3ddbdcabf0)
getattr called! ('/test', 0x7f3ddb5c9bf0)


# Test run again, file already exists - We only see getattrs #
getattr called! ('/test', 0x7f3ddbdcac20)
getattr called! ('/test', 0x7f3ddbdcabf0)
getattr called! ('/test', 0x7f3ddb5c9bf0)

I tested this using the fusexmp_fh.c source from the fuse 2.9.7 release, with some extra logging + options added (I've marked the custom bits with /* debug */ for clarity).

The full sources I used are attached below.

fusefgetattrbug.zip

Cheers,

  • Alex.

fuse 2.9.4 on ubuntu 15.10 exhibits an infinite negative cache

Hi.

I observe this behavior both with sshfs and our filesystem implementation: rm-ing a file will make fuse return ENOENT on future stat calls to the file, without making any call to the filesystem backend, forever.

Steps to reproduce with sshfs:

local> sshfs remote@remote: /mnt/remote
local> cd /mnt/remote
remote> touch pan
local> rm pan
remote> touch pan
local> sleep 10 #or any amount of time
local> ls
ls: cannot access pan: No such file or directory
pan
local> stat pan
stat: cannot stat ‘pan’: No such file or directory

The issue is not present with fuse 2.9.2 on ubuntu 14.04.

Best regards,

Configurable thread pool for high level API

Currently the thread pool for the high level API will grow as needed but threads will self destruct if after their handling of a request there is greater than 10 threads. The overhead of doing so is probably much greater than the request handled and limits throughput.

The max number of threads should be configurable and maybe a smarter algo used which perhaps cleans up threads if unused for a time rather than checking every request.

include protocol documentation

The kernel protocol does not seem to be well documented. It would ease development of alternative libraries and features if there was a proper document describing the /dev/fuse protocol and it's general use.

Release path convention "broken"

There's not been much of a convention in past releases, but it looks like you've switched from using underscores to periods in the version identifier. 2_9_5 has become 2.9.6

https://github.com/libfuse/libfuse/releases/download/fuse-2.9.6/fuse-2.9.6.tar.gz
https://github.com/libfuse/libfuse/releases/download/fuse_2_9_5/fuse-2.9.5.tar.gz
https://github.com/libfuse/libfuse/releases/download/fuse_2_9_4/fuse-2.3.0.tar.gz

Can you settle on one way or the other? It's making it hard to automate the install, specifically through the chef receive at https://github.com/twilson63/s3fs-recipe

Inconsistent symbol versioning in libfuse.so

readelf -Ws /usr/lib/libfuse.so | grep fuse_new
298: 00000000000153e0 75 FUNC GLOBAL DEFAULT 11 fuse_new_compat2@@FUSE_2.2
315: 0000000000015490 153 FUNC GLOBAL DEFAULT 11 fuse_new@FUSE_2.5
316: 00000000000153e0 75 FUNC GLOBAL DEFAULT 11 fuse_new
317: 0000000000015080 67 FUNC GLOBAL DEFAULT 11 fuse_new@@FUSE_2.6
-> fuse_new == fuse_new_compat2@@FUSE_2.2
I think it should be fuse_new@@FUSE_2.6 or it should be removed.

readelf -Ws /usr/lib/libfuse.so | grep fuse_main
209: 00000000000200d0 97 FUNC GLOBAL DEFAULT 11 fuse_main@@FUSE_2.2
210: 00000000000206c0 78 FUNC GLOBAL DEFAULT 11 fuse_main
243: 0000000000020670 78 FUNC GLOBAL DEFAULT 11 fuse_main_compat1@@FUSE_2.2
244: 00000000000206c0 78 FUNC GLOBAL DEFAULT 11 fuse_main_compat2@@FUSE_2.2
-> fuse_main == fuse_main_compat2@@FUSE_2.2
I think it should be fuse_main@@FUSE_2.2 or it should be removed.

For example the fuse_mount has only versioned symbols, so loading the "fuse_mount" symbol we get the fuse_mount@@FUSE_2.6, the default version. However loading "fuse_new" will load the symbol from another version of the API.

OS: Gentoo Linux
Package version: sys-fs/fuse-2.9.4

so version has not been upgraded to 2.9.5

Previous releases of fuse (libfuse) had package and so versions identical:

fuse-2.9.x -> libfuse.so.2.9.x

In present version 2.9.5, should be libfuse.so.2.9.5, not libfuse.so.2.9.4 . This has not been done.

It is defined in lib/Makefile.am, and should be

libfuse_la_LDFLAGS = -pthread @libfuse_libs@ -version-number 2:9:5 \

not

libfuse_la_LDFLAGS = -pthread @libfuse_libs@ -version-number 2:9:4 \

For users, fix just changing lib/Makefile.in with

sed -i  's/2:9:4/2:9:5/' lib/Makefile.in

For the package, tested the same with lib/Makefile.am:

sed -i  's/2:9:4/2:9:5/' lib/Makefile.am

but needed to autoreconf.

Please, tell me if you need any other info.

Thanks.

Improve support for ACLs

Currently FUSE file systems that want to support ACLs are completely on their own: they have to implement their own ACL checking, they have to manually keep ACLs and Unix permissions synchronized, and they need to write their own code to convert ACLs to extended attributes and back.

Ideally:

  • The FUSE kernel module would do all ACL checking when the default_permissions option is used
  • The FUSE kernel module or libfuse would keep ACLs and Unix permissions in sync, i.e. a setxattr() request that modifies ACLs would automatically also trigger a setattr request to update Unix permissions appropriately (and vice versa if required)

That way, any FUSE file system that supports extended attributes would also be able to support ACLs.

Generate unittest coverage information

Where can I be able to get info of the tests coverage? Is it available somewhere in coveralls.io or there's plans for it? Having the tests passing on TravisCI it should be trivial to generate and update that info...

Ambiguous conditional expression

While compiling with gcc-5.3.0 I noticed the following warning:

ulockmgr_server.c: In function ‘receive_message’:
ulockmgr_server.c:95:24: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
   if (!cmsg->cmsg_type == SCM_RIGHTS) {
                        ^

The warning seems legit. It should be replaced with:

   if (cmsg->cmsg_type != SCM_RIGHTS) {

With kernel 4.4.0, "mount -o loop" hangs against a file in a 'direct_io' fuse mount

I am using the handle-based example that comes with the FUSE download.

This problem manifests in kernel 4.4.0. No such problem is seen in kernel 3.16.0

Trying to create a loop mount for a disk image file in a fuse mount hangs if the fuse mount was created with the 'direct_io' option:

# mount fuse WITH 'direct_io'
$ example/fusexmp_fh -o direct_io /tmp/fusexmp/fuse-exmp-mnt

# trying to loop mount an image file hangs
$ mount -o loop /tmp/fuse-exmp-mnt/share_disk.img /tmp/fuse-looptest
<hangs>

$ ps -elf | grep mount
0 D root     17114  3767  0  80   0 -  4676 lock_p 12:25 pts/1    00:00:00 mount -o loop /tmp/fuse-exmp-mnt/share_disk.img /tmp/fuse-looptest

No hang is seen (even in kernel 4.4.0) if 'direct_io' isn't specified for the fuse mount:

# mount fuse WITHOUT 'direct_io'
$ example/fusexmp_fh /tmp/fusexmp/fuse-exmp-mnt

# trying to loop mount an image file works this time
$ mount -o loop /tmp/fuse-exmp-mnt/share_disk.img /tmp/fuse-looptest
<works>

I am using kernel 4.4.0-21-generic and fuse library 2.9.0.

/var/log/messages has call traces fingering fuse_direct_io() and fuse_release_user_pages():

Jun 16 12:09:51 Node001 kernel: [ 1200.163685] loop0           D ffff8800aa90b8e8     0  3935      2 0x00000000
Jun 16 12:09:51 Node001 kernel: [ 1200.163691]  ffff8800aa90b8e8 ffffffff81e12540 ffff8800aab08000 ffff8800aa90b908
Jun 16 12:09:51 Node001 kernel: [ 1200.163694]  ffff8800aa90c000 0000000000000000 7fffffffffffffff 0000000000000002
Jun 16 12:09:51 Node001 kernel: [ 1200.163697]  ffffffff81806970 ffff8800aa90b908 ffffffff81806289 ffff8800aa90b958
Jun 16 12:09:51 Node001 kernel: [ 1200.163700] Call Trace:
Jun 16 12:09:51 Node001 kernel: [ 1200.163713]  [<ffffffff81806970>] ? out_of_line_wait_on_atomic_t+0xd0/0xd0
Jun 16 12:09:51 Node001 kernel: [ 1200.163717]  [<ffffffff81806289>] schedule+0x39/0x80
Jun 16 12:09:51 Node001 kernel: [ 1200.163720]  [<ffffffff81808c82>] schedule_timeout+0x222/0x2b0
Jun 16 12:09:51 Node001 kernel: [ 1200.163726]  [<ffffffff8102d65b>] ? __switch_to+0x1bb/0x570
Jun 16 12:09:51 Node001 kernel: [ 1200.163732]  [<ffffffff810f0a85>] ? ktime_get+0x35/0xa0
Jun 16 12:09:51 Node001 kernel: [ 1200.163736]  [<ffffffff81806970>] ? out_of_line_wait_on_atomic_t+0xd0/0xd0
Jun 16 12:09:51 Node001 kernel: [ 1200.163739]  [<ffffffff81805787>] io_schedule_timeout+0xa7/0x110
Jun 16 12:09:51 Node001 kernel: [ 1200.163742]  [<ffffffff8180698f>] bit_wait_io+0x1f/0x60
Jun 16 12:09:51 Node001 kernel: [ 1200.163745]  [<ffffffff81806591>] __wait_on_bit_lock+0x71/0xb0
Jun 16 12:09:51 Node001 kernel: [ 1200.163751]  [<ffffffff811871ee>] __lock_page+0xae/0xb0
Jun 16 12:09:51 Node001 kernel: [ 1200.163757]  [<ffffffff810c0800>] ? wake_atomic_t_function+0x30/0x30    
Jun 16 12:09:51 Node001 kernel: [ 1200.163761]  [<ffffffff81191d32>] set_page_dirty_lock+0x42/0x50
Jun 16 12:09:51 Node001 kernel: [ 1200.163766]  [<ffffffff8130c0a0>] fuse_release_user_pages.isra.22+0x50/0x70
Jun 16 12:09:51 Node001 kernel: [ 1200.163770]  [<ffffffff8130e783>] fuse_direct_io+0x3b3/0x590
Jun 16 12:09:51 Node001 kernel: [ 1200.163773]  [<ffffffff8130e9b5>] __fuse_direct_read+0x55/0x80
Jun 16 12:09:51 Node001 kernel: [ 1200.163776]  [<ffffffff8130ea19>] fuse_direct_read_iter+0x39/0x40
Jun 16 12:09:51 Node001 kernel: [ 1200.163781]  [<ffffffff812047e2>] vfs_iter_read+0x62/0xa0
Jun 16 12:09:51 Node001 kernel: [ 1200.163787]  [<ffffffff8155c7e5>] lo_read_simple.isra.26+0xb5/0x1f0
Jun 16 12:09:51 Node001 kernel: [ 1200.163791]  [<ffffffff8155d8ed>] loop_queue_work+0x51d/0x730
Jun 16 12:09:51 Node001 kernel: [ 1200.163794]  [<ffffffff810b7cd6>] ? put_prev_task_fair+0x26/0x40
Jun 16 12:09:51 Node001 kernel: [ 1200.163798]  [<ffffffff81805b3d>] ? __schedule+0x34d/0x9b1
Jun 16 12:09:51 Node001 kernel: [ 1200.163802]  [<ffffffff8109e509>] kthread_worker_fn+0x79/0x160
Jun 16 12:09:51 Node001 kernel: [ 1200.163805]  [<ffffffff8109e490>] ? flush_kthread_worker+0x70/0x70
Jun 16 12:09:51 Node001 kernel: [ 1200.163807]  [<ffffffff8109e339>] kthread+0xc9/0xe0
Jun 16 12:09:51 Node001 kernel: [ 1200.163810]  [<ffffffff8109e270>] ? kthread_stop+0x100/0x100
Jun 16 12:09:51 Node001 kernel: [ 1200.163813]  [<ffffffff81809e4f>] ret_from_fork+0x3f/0x70
Jun 16 12:09:51 Node001 kernel: [ 1200.163816]  [<ffffffff8109e270>] ? kthread_stop+0x100/0x100

Any help on this issue would be appreciated.

Thanks,

Tags don't match download tar

Hi! Welcome to github. Nice to find you here.

I've just hit upon a minor annoyance, and it might be good to correct it sooner rather than later. I'm scripting something which builds fuse, and it looks something like (pseudocode):

FUSE_VERSION=2.9.5
FUSE_HASH=ab1231231232113213123
curl https://github.com/libfuse/libfuse/releases/download/fuse-$VERSION/fuse-$VERSION.tar.gz
verify-hash fuse-$VERSION $FUSE_HASH
tar zxf fuse-$VERSION.tar.gz
cd fuse-$VERSION

The only annoyance with this is that the download URL follows the git tag. Since the git tags have underscores, the link is:

https://github.com/libfuse/libfuse/releases/download/fuse_2_9_5/fuse-2.9.5.tar.gz

So it's not possible to just update one $FUSE_VERSION, you also have to update the URL separately, to represent the fuse_2_9_5 part. It would be nice to just have the one variable to update. Is it possible to use fuse-2.9.5 tags instead? It would make life easier.

Thanks for your consideration, and I won't be disappointed if you decline.

Does libfuse support LVM?

I use fuse to design a software for mounting lvm on linux system.
But faild and its log is folloing '
warning: command line show the following error msg :
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

unionfs-fuse freeze, starting with Linux 4.0

Hello,

This a continuation of an unionfs-fuse issue:

Using unionfs-fuse, here is a simple script that freezes the caller when accessing to the mounted directory. After some tests, it appears that this script is working with previous versions of the kernel's fuse-api (with any version of unionfs or fuse even the latests).

On <v4 kernel, it works (kernel/fuse api up to 7.22).
On 4+ kernels (or kernel's fuse-api 7.23), it freezes (the script stops on the "freezing?" message, a reboot is needed to sort this out)

#!/bin/sh
set -x
while umount /tmp/test; do true; done
set -e
rm -rf /tmp/rw
mkdir -p /tmp/test /tmp/rootbind /tmp/rw
date > /tmp/test/a
mount -o bind / /tmp/rootbind
unionfs -o allow_other,use_ino,suid,dev,nonempty,cow /tmp/rw=RW:/tmp/rootbind/tmp/test=RO /tmp/test
echo freezing?
echo not freezing >> /tmp/test/a
cat /tmp/test/a
cat /tmp/rootbind/tmp/test/a

`-o default_permissions` ignores restricted deletion flag

When using -o default_permissions,allow_other users are able to delete directory entries not owned by them even if the parent directory has the restricted deletion flag set.

This is probably the right behavior for the mounting user (as he is effectively root), but should not be possible for other users.

Allow for 'fh' to be set from any function

Currently fuse_file_info.fh can only be set on open/create/opendir but it'd be useful to be able to change the value from any function in which fuse_file_info is used.

Is there a reason the structure passed in is a copy rather than the original? If parts of it are read only it should be on the user not to change them or separate out into one const and one non-const struct.

Without `default_permissions`, cached permissions are only checked on first access

When the inodes are cached by fuse (non-zero attr_timeout), and the standard_permissions are used, the following sequence :

chmod 755 trydir
rm -rf trydir
mkdir trydir
echo file > trydir/file
ls -li trydir/file    
chmod 000 trydir
chmod 444 trydir/file
ls -li trydir/file

outputs :

293 -rw-rw-r-- 1 linux linux 5 2009-08-25 17:50 trydir/file
293 -r--r--r-- 1 linux linux 5 2009-08-25 17:50 trydir/file

The "chmod 000" should have led to an EACCES error for the subsequent commands.

This was reported in 2009 (http://article.gmane.org/gmane.comp.file-systems.fuse.devel/8099), and according to http://article.gmane.org/gmane.comp.file-systems.fuse.devel/15300 some work is still needed on it.

This means that for being Posix compliant, fuse file systems cannot either use the cache or have the permissions checked by the kernel.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.