Bug#982806: sshfs: SIGSEGV when using max_conns > 1

[Miklos Szeredi]

[Cc Timo Savola, the author of the "max_conns=" feature]

On Sun, Feb 14, 2021 at 7:09 PM Peter Gerber  wrote:
>
> Package: sshfs
> Version: 3.7.1+repack-1
> Severity: important
>
> Dear Maintainer,
>
> the following steps crash sshfs with SIGSEGV when a file is open while
> the folder containing it is renamed.
>
> Steps to reproduce:
>
> #!/usr/bin/python3
> import os
>
> os.mkdir('old_name')
> f = open('old_name/f', 'w')
> os.rename('old_name', 'new_name')
> f.close()  # crashes here
>
>
> Output from gdb:
>
> user@media:~/sshfs/sshfs-fuse-3.7.1+repack/build$ gdb -ex r --args sshfs
> mia.arbitrary.ch:/ /home/user/b -f -d -o max_conns=2
> GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
> Copyright (C) 2021 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from sshfs...
> Reading symbols from
> /usr/lib/debug/.build-id/0c/1ef7b947ed8cfbdddaa25f2bf189b9bf14347e.debug...
> Starting program: /usr/bin/sshfs mia.arbitrary.ch:/ /home/user/b -f -d
> -o max_conns=2
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> SSHFS version 3.7.1
> [Detaching after fork from child process 15132]
> [Detaching after fork from child process 15134]
> executing  <-x> <-a> <-oClearAllForwardings=yes> <-2>
>  <-s> 
> Server version: 3
> Extension: posix-ren...@openssh.com <1>
> Extension: stat...@openssh.com <2>
> Extension: fstat...@openssh.com <2>
> Extension: hardl...@openssh.com <1>
> Extension: fs...@openssh.com <1>
> Extension: lsets...@openssh.com <1>
> [New Thread 0x77be1700 (LWP 15136)]
> [New Thread 0x772de700 (LWP 15137)]
> [New Thread 0x769db700 (LWP 15138)]
> [1] LSTAT
>   [1]  ATTRS   41bytes (3ms)
> [2] LSTAT
>   [2]  ATTRS   41bytes (2ms)
> [3] LSTAT
>   [3]  ATTRS   41bytes (1ms)
> [4] LSTAT
>   [4]  ATTRS   41bytes (1ms)
> [5] LSTAT
>   [5] STATUS   33bytes (3ms)
> [6] LSTAT
>   [6] STATUS   33bytes (3ms)
> [7] MKDIR
>   [7] STATUS   28bytes (2ms)
> [8] LSTAT
>   [8]  ATTRS   41bytes (2ms)
> [9] LSTAT
>   [9] STATUS   33bytes (1ms)
> [00010] OPEN
> [00011] LSTAT
>   [00010] HANDLE   17bytes (1ms)
>   [00011]  ATTRS   41bytes (1ms)
> [00012] FSTAT
>   [00012]  ATTRS   41bytes (1ms)
> [Detaching after fork from child process 15140]
> executing  <-x> <-a> <-oClearAllForwardings=yes> <-2>
>  <-s> 
> Server version: 3
> Extension: posix-ren...@openssh.com <1>
> Extension: stat...@openssh.com <2>
> Extension: fstat...@openssh.com <2>
> Extension: hardl...@openssh.com <1>
> Extension: fs...@openssh.com <1>
> Extension: lsets...@openssh.com <1>
> [New Thread 0x761da700 (LWP 15142)]
> [00013] LSTAT
>   [00013] STATUS   33bytes (1ms)
> [00014] EXTENDED
>   [00014] STATUS   28bytes (1ms)
> [New Thread 0x759d9700 (LWP 15143)]
> [00015] CLOSE
>
> Thread 2 "sshfs" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x77be1700 (LWP 15136)]
> --Type  for more, q to quit, c to continue without paging--c
> 0x55560423 in sshfs_release (path=0x7f60
> "/media/_unsorted/_in/new_name/f", fi=0x77be0d30) at ../sshfs.c:2890
> 2890ce->refcount--;
> (gdb) t 2
> [Switching to thread 2 (Thread 0x77be1700 (LWP 15136))]
> #0  0x55560423 in sshfs_release (path=0x7f60
> "/media/_unsorted/_in/new_name/f",
> fi=0x77be0d30) at ../sshfs.c:2890
> 2890ce->refcount--;
> (gdb) bt
> #0  0x55560423 in sshfs_release (path=0x7f60
> "/media/_unsorted/_in/new_name/f",
> fi=0x77be0d30) at ../sshfs.c:2890
> #1  0x77f82cba in fuse_do_release (f=0x55571080, ino=6,
> path=0x7f60 "/media/_unsorted/_in/new_name/f", fi= out>) at ../lib/fuse.c:3142
> #2  0x77f85cb6 in fuse_lib_release (req=0x70001fb0, ino=6,
> fi=0x77be0d30) at ../lib/fuse.c:4121
> #3  0x77f8c8c6 in do_release (req=,
> nodeid=, inarg=)
> at ../lib/fuse_lowlevel.c:1455
> #4  0x77f8ea73 in fuse_session_process_buf_int
> (se=0x55571460, buf=buf@entry=0x55591bb0,
> ch=) at ../lib/fuse_lowlevel.c:2666
> #5  

Bug#898984: fuse: Enable user_allow_other by default

[Miklos Szeredi]

On Fri, May 18, 2018 at 10:51 AM, Dmitry Bogatov  wrote:
> Package: fuse
> Version: 2.9.7-1
> Severity: wishlist
>
> Dear Maintainer,
>
> Is there any security or other concerns about enabling `user_allow_other'
> in /etc/fuse.conf by default?

There are security concerns with this.   For details see
Documentation/filesystems/fuse.txt in the linux kernel tree.  The
following paragraphs are relevant:

 B) If another user is accessing files or directories in the
filesystem, the filesystem daemon serving requests can record the
exact sequence and timing of operations performed.  This
information is otherwise inaccessible to the mount owner, so this
counts as an information leak.

The solution to this problem will be presented in point 2) of C).

 C) There are several ways in which the mount owner can induce
undesired behavior in other users' processes, such as:

 1) mounting a filesystem over a file or directory which the mount
owner could otherwise not be able to modify (or could only
make limited modifications).

This is solved in fusermount, by checking the access
permissions on the mountpoint and only allowing the mount if
the mount owner can do unlimited modification (has write
access to the mountpoint, and mountpoint is not a "sticky"
directory)

 2) Even if 1) is solved the mount owner can change the behavior
of other users' processes.

 i) It can slow down or indefinitely delay the execution of a
   filesystem operation creating a DoS against the user or the
   whole system.  For example a suid application locking a
   system file, and then accessing a file on the mount owner's
   filesystem could be stopped, and thus causing the system
   file to be locked forever.

 ii) It can present files or directories of unlimited length, or
   directory structures of unlimited depth, possibly causing a
   system process to eat up diskspace, memory or other
   resources, again causing DoS.

[...]

If a sysadmin trusts the users enough, or can ensure through other
measures, that system processes will never enter non-privileged
mounts, it can relax the last limitation with a "user_allow_other"
config option.  If this config option is set, the mounting user can
add the "allow_other" mount option which disables the check for other
users' processes.

Thanks,
Miklos

Bug#836211: dpkg: Cannot upgrade some packages on overlayfs: Invalid cross-device link

[Miklos Szeredi]

On Fri, Sep 02, 2016 at 03:03:54PM +0200, Guillem Jover wrote:
> Hi!
> 
> On Fri, 2016-09-02 at 14:30:58 +0200, Miklos Szeredi wrote:
> > You are the first to report that this quirk actually causes problems
> > in real life.
> > 
> > I have plans to fix this by adding a "redirector" attribute so that
> > copied up directories (and perhaps files) can refer to lower directory
> > that is found at a different location relative to the root of the
> > overlay from the location of the upper directory.
> > 
> > Maybe an example can make this more clear:
> > 
> > lower/foo/bar/baz
> > upper/foo/bar <- whiteout
> > upper/moved/here <- redirects to "foo/bar"
> > 
> > will result in the tree:
> > 
> > overlay/moved/here/baz
> 
> That'd be very much appreciated, thanks!

Toy patch attached.  Passes minimal test.

It does not deal with multi-layer setups when one of the lower layers was
previously an upper layer (generally overlayfs does support this, so this patch
will need to deal with that case).

You can help by

 - review it
 - improve it
 - test it
 - break it
 - write test cases in xfstests

Thanks,
Miklos

---
 fs/overlayfs/dir.c   |   42 --
 fs/overlayfs/overlayfs.h |1 
 fs/overlayfs/super.c |   89 +--
 3 files changed, 119 insertions(+), 13 deletions(-)

--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -764,6 +764,31 @@ static int ovl_rmdir(struct inode *dir,
return ovl_do_remove(dentry, true);
 }
 
+static bool ovl_can_move(struct dentry *dentry, enum ovl_path_type type)
+{
+// return !d_is_dir(dentry) || !OVL_TYPE_MERGE_OR_LOWER(type);
+   return true;
+}
+
+static int ovl_set_redirect(struct dentry *dentry)
+{
+   char *buf = __getname();
+   char *path;
+   int err;
+
+   if (!buf)
+   return -ENOMEM;
+
+   path = dentry_path_raw(dentry, buf, PATH_MAX);
+
+   printk(KERN_WARNING "redirect: <%s>\n", path);
+   err = ovl_do_setxattr(ovl_dentry_upper(dentry), OVL_XATTR_REDIRECT,
+ path, strlen(path), 0);
+   __putname(buf);
+
+   return err;
+}
+
 static int ovl_rename2(struct inode *olddir, struct dentry *old,
   struct inode *newdir, struct dentry *new,
   unsigned int flags)
@@ -798,7 +823,7 @@ static int ovl_rename2(struct inode *old
/* Don't copy up directory trees */
old_type = ovl_path_type(old);
err = -EXDEV;
-   if (OVL_TYPE_MERGE_OR_LOWER(old_type) && is_dir)
+   if (!ovl_can_move(old, old_type))
goto out;
 
if (new->d_inode) {
@@ -811,7 +836,7 @@ static int ovl_rename2(struct inode *old
 
new_type = ovl_path_type(new);
err = -EXDEV;
-   if (!overwrite && OVL_TYPE_MERGE_OR_LOWER(new_type) && 
new_is_dir)
+   if (!overwrite && !ovl_can_move(new, new_type))
goto out;
 
err = 0;
@@ -883,7 +908,6 @@ static int ovl_rename2(struct inode *old
 
trap = lock_rename(new_upperdir, old_upperdir);
 
-
olddentry = lookup_one_len(old->d_name.name, old_upperdir,
   old->d_name.len);
err = PTR_ERR(olddentry);
@@ -920,11 +944,23 @@ static int ovl_rename2(struct inode *old
if (newdentry == trap)
goto out_dput;
 
+   printk(KERN_WARNING "is_dir: %i, old_opaque: %i, old_type: %i\n",
+  is_dir, old_opaque, old_type);
+   if (is_dir && OVL_TYPE_MERGE_OR_LOWER(old_type)) {
+   err = ovl_set_redirect(old);
+   if (err)
+   goto out_dput;
+   }
if (is_dir && !old_opaque && new_opaque) {
err = ovl_set_opaque(olddentry);
if (err)
goto out_dput;
}
+   if (!overwrite && new_is_dir && OVL_TYPE_MERGE_OR_LOWER(new_type)) {
+   err = ovl_set_redirect(new);
+   if (err)
+   goto out_dput;
+   }
if (!overwrite && new_is_dir && old_opaque && !new_opaque) {
err = ovl_set_opaque(newdentry);
if (err)
--- a/fs/overlayfs/overlayfs.h
+++ b/fs/overlayfs/overlayfs.h
@@ -26,6 +26,7 @@ enum ovl_path_type {
 
 #define OVL_XATTR_PREFIX XATTR_TRUSTED_PREFIX "overlay."
 #define OVL_XATTR_OPAQUE OVL_XATTR_PREFIX "opaque"
+#define OVL_XATTR_REDIRECT OVL_XATTR_PREFIX "redirect"
 
 #define OVL_ISUPPER_MASK 1UL
 
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -285,6 +285,33 @@ static bool ovl_is_opaquedir(struct dent
return false;
 }
 
+static int ovl_check_redir

Bug#836211: dpkg: Cannot upgrade some packages on overlayfs: Invalid cross-device link

[Miklos Szeredi]

On Fri, Sep 2, 2016 at 1:36 PM, Raphael Hertzog  wrote:
> Hi,
>
> On Wed, 31 Aug 2016, Felipe Sateler wrote:
>> overlayfs does not support renaming directories when the directories
>> live in the lower filesystem:
> [...]
>> Unfortunately this means that dpkg fails at least in the case where a
>> directory is converted into a file: apt 1.3~rc2 moves
>> /usr/share/bug/apt/script to /usr/share/bug/apt . This causes dpkg to
>
> That's the change at the package level. The operation that fails
> at the dpkg level is rename('/usr/share/bug/apt', 
> '/usr/share/bug/apt.dpkg-tmp').
>
>> fail when running in an overlayfs with the following error:
> [...]
>>  unable to move aside './usr/share/bug/apt' to install new version: Invalid 
>> cross-device link
>
> I got the same failure here but I also saw similar reports in a Kali live
> system where overlayfs is used for persistence (and with the upgrade
> of gedit). So that error is affecting many Kali users. It's not a
> very rare error (ex: https://bugs.kali.org/view.php?id=3473,
> https://bugs.kali.org/view.php?id=3476,
> https://bugs.kali.org/view.php?id=3361,
> https://bugs.kali.org/view.php?id=3365).
>
> I'm putting in copy the overlayfs kernel maintainer... Hello Miklos,
> that restriction above (cf
> https://github.com/torvalds/linux/blob/v4.8-rc2/fs/overlayfs/copy_up.c#L318-L322)
> is very problematic for us.
>
> Do you have plans to get rid of it?

You are the first to report that this quirk actually causes problems
in real life.

I have plans to fix this by adding a "redirector" attribute so that
copied up directories (and perhaps files) can refer to lower directory
that is found at a different location relative to the root of the
overlay from the location of the upper directory.

Maybe an example can make this more clear:

lower/foo/bar/baz
upper/foo/bar <- whiteout
upper/moved/here <- redirects to "foo/bar"

will result in the tree:

overlay/moved/here/baz

> It does not seem very correct to put the burden on user-space to be aware
> of overlayfs restrictions such as this one. Renaming a directory is
> not something that happens often in practice in the uses cases where
> we use overlayfs but it's still frequent enough to deserve better than
> a EXDEV error IMO and dpkg trying to rename "foo/" into "foo.dpkg-tmp/"
> is in its right to assume that this rename will not cross any device
> boundary.

The EXDEV trick  just works for mv(1), hence this didn't seem to be a
big issue in practice.

Thanks,
Miklos

Bug#741471: sshfs instantly unmounts when called via desktop entry

[Miklos Szeredi]

On Wed, Mar 12, 2014 at 9:36 PM, Vladimir Kudrya pzs...@yandex.ru wrote:
 Package: sshfs
 Version: 2.5-1
 Severity: normal

 Dear Maintainer, there is a bug in sshfs which breaks mounts in some
 specific use cases.

 When it works:
 Open terminal, execute:
  sshfs user@server:/dir /some/local/mountpoint
 Close terminal. Mount persists, everything works.

 When it does not work:
 - Execution via desktop entry
 - Execution as an argument for terminal
 - Execution in the script called as an argument for terminal

 To reproduce, create desktop entry with parameters:
 
 Exec=sshfs user@server:/dir /some/local/mountpoint
 Terminal=true
 
 Launch desktop entry, enter password for sshfs.
 As soon as terminal is closed, sshfs mount disappears.

Possibly a race (terminal closed before child can execute setsid).

Instead of running in a terminal try the SSH_ASKPASS mechanism to pop
up a window asking for the ssh password (works by default here)

E.g.

  setsid sshfs ...
  window pops up

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738309: sshfs-fuse: Return the correct X_OK access for sshfs mounts.

[Miklos Szeredi]

On Sun, Feb 9, 2014 at 1:56 AM, Artur Rona ari-tc...@tlen.pl wrote:
 Package: sshfs-fuse
 Version: 2.5-1
 Tags: patch
 Usertags: origin-ubuntu ubuntu-patch trusty

 In Ubuntu, we've applied the attached patch to achieve the following:

   *   debian/patches/lp1017870.patch:
   + Return the correct X_OK access for sshfs mounts.

 We thought you might be interested in doing the same.

Pushed to git.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#670926: fopen: File exists (errno = 17) error when saving mutt attachment to sshfs

[Miklos Szeredi]

On Fri, Dec 13, 2013 at 6:10 PM, Bartosz Feński bart...@fenski.pl wrote:

 Do you plan to release new version of sshfs that will include this patch
 or should I patch 2.4 version available in Debian?

Pushed fix to git.   I'll release a new version next week.

Thanks,
Miklos


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724690: sshfs: user's mountpoint is not accessible by root

[Miklos Szeredi]

On Fri, Sep 27, 2013 at 10:56 AM, Alessandro Vesely ves...@tana.it wrote:
 On Thu 26/Sep/2013 19:04:19 +0200 Bastien ROUCARIES wrote:

 Not a bug a security feature SEE fuse man page.

 I understand those security concerns.  What I'm asking is that just
 the mountpoint be accessible to root, not the remote files.  That
 would be enough for root to learn that the directory contents reside
 on a different device.  I see no other way to avoid breaking scripts
 such as check-setuid (package checksecurity).

Distro people should start thinking about doing per-user namespaces.
It would clean up the fuse mount vs. root access mess.

Not sure who would be responsible for such decisions.  Perhaps as a
first step, PAM maintainer could be asked?

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700824: libfuse2: Memory leak in process_opt_param (fuse_opt.c)

[Miklos Szeredi]

On Sun, Feb 17, 2013 at 11:49 PM, Marco Schuster ma...@m-s-d.eu wrote:
 Package: libfuse2
 Version: 2.9.0-2+deb7u1
 Severity: normal
 Tags: upstream

 In the source file lib/fuse_opt.c, the function process_opt_param leaks
 memory by silently overwriting *(char **) var = copy; in line 218.

That's true.   But there's a but.  The previous value may not have
been initialized and then we may not be able to free it.  The app is
probably broken at that point anyway, yet we don't want to make it
more broken.

I guess I'll fix this in libfuse-3.0 and document it in the header file.

Thanks,
Miklos


 -- System Information:
 Debian Release: wheezy/sid
   APT prefers testing
   APT policy: (500, 'testing')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages libfuse2 depends on:
 ii  libc6  2.13-33
 ii  multiarch-support  2.13-33

 libfuse2 recommends no packages.

 Versions of packages libfuse2 suggests:
 ii  fuse  2.9.0-2+deb7u1

 -- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700824: libfuse2: Memory leak in process_opt_param (fuse_opt.c)

[Miklos Szeredi]

On Mon, Feb 18, 2013 at 3:27 PM, Marco Schuster ma...@m-s-d.eu wrote:
 On Mon, Feb 18, 2013 at 3:23 PM, Miklos Szeredi mik...@szeredi.hu wrote:
 On Sun, Feb 17, 2013 at 11:49 PM, Marco Schuster ma...@m-s-d.eu wrote:
 In the source file lib/fuse_opt.c, the function process_opt_param leaks
 memory by silently overwriting *(char **) var = copy; in line 218.

 That's true.   But there's a but.  The previous value may not have
 been initialized and then we may not be able to free it.  The app is
 probably broken at that point anyway, yet we don't want to make it
 more broken.

 I found out about this as PHP tracks the memory it allocated with its
 own emalloc and friends and complains when you don't call efree() on
 them all. But I don't see any way to fix this for real, as every
 external application can use its own memory/heap allocator...

 Marco

Added this patch to 3.0.

Thanks,
Miklos


fuse_opt_parse-fix-memory-leak.patch
Description: Binary data

Bug#690144: sshfs crashed with SIGABRT in __libc_message()

[Miklos Szeredi]

This is likely fixed in fuse-2.9.1.

The changelog for the fix is:

commit 3c4c063a2fd5cc6e9ce2b5db82e2a0dfa59b2e40
Author: Miklos Szeredi mszer...@suse.cz
Date:   Thu Jul 19 15:05:56 2012 +0200

Fix crash caused by freeing a stack address

The failure path of try_get_path2() erronously tried to free the
path1 value (an address on the stack) instead of the allocated
string pointed to by path1.  This caused the library to crash.

Reported by Itay Perl


Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#670926: fopen: File exists (errno = 17) error when saving mutt attachment to sshfs

[Miklos Szeredi]

Louis-David Mitterrand l...@apartia.fr writes:

 On Wed, May 16, 2012 at 10:36:43PM +0200, Miklos Szeredi wrote:
 
  Hi,
 
  Please find the strace attached.
 
 Thanks.
 
 Still I have no clues, the EEXIST error is not seen in any of the system
 calls and I can't see fopen returning EEXIST for any reason.
 
 Can you try ltrace as well?   Though I don't have high hopes of that
 revealing anything...

 Hi,

 Please find the ltrace outuput attached.

Can you please try the disable_hardlink option added by the attached
patch?

Thanks,
Miklos

diff --git a/sshfs.1 b/sshfs.1
index d316930..c045b3c 100644
--- a/sshfs.1
+++ b/sshfs.1
@@ -141,6 +141,11 @@ directly connect to PORT bypassing ssh
 \fB\-o\fR slave
 communicate over stdin and stdout bypassing network
 .TP
+\fB\-o\fR disable_hardlink
+link(2) will return with errno set to ENOSYS.  Hard links don't currently work
+perfectly on sshfs, and this confuses some programs.  If that happens try
+disabling hard links with this option.
+.TP
 \fB\-o\fR transform_symlinks
 transform absolute symlinks to relative
 .TP
diff --git a/sshfs.c b/sshfs.c
index 4945302..2e3d84a 100644
--- a/sshfs.c
+++ b/sshfs.c
@@ -203,6 +203,7 @@ struct sshfs {
 	int detect_uid;
 	int idmap;
 	int nomap;
+	int disable_hardlink;
 	char *uid_file;
 	char *gid_file;
 	GHashTable *uid_map;
@@ -358,6 +359,7 @@ static struct fuse_opt sshfs_opts[] = {
 	SSHFS_OPT(password_stdin,password_stdin, 1),
 	SSHFS_OPT(delay_connect, delay_connect, 1),
 	SSHFS_OPT(slave, slave, 1),
+	SSHFS_OPT(disable_hardlink,  disable_hardlink, 1),
 
 	FUSE_OPT_KEY(-p ,KEY_PORT),
 	FUSE_OPT_KEY(-C, KEY_COMPRESS),
@@ -2192,7 +2194,7 @@ static int sshfs_link(const char *from, const char *to)
 {
 	int err = -ENOSYS;
 
-	if (sshfs.ext_hardlink) {
+	if (sshfs.ext_hardlink  !sshfs.disable_hardlink) {
 		struct buffer buf;
 
 		buf_init(buf, 0);
@@ -3190,6 +3192,7 @@ static void usage(const char *progname)
 -o sftp_server=SERVpath to sftp server or subsystem (default: sftp)\n
 -o directport=PORT directly connect to PORT bypassing ssh\n
 -o slave   communicate over stdin and stdout bypassing network\n
+-o disable_hardlinklink(2) will return with errno set to ENOSYS\n
 -o transform_symlinks  transform absolute symlinks to relative\n
 -o follow_symlinks follow symlinks on the server\n
 -o no_check_root   don't check for existence of 'dir' on server\n

Bug#670926: fopen: File exists (errno = 17) error when saving mutt attachment to sshfs

[Miklos Szeredi]

Louis-David Mitterrand l...@apartia.fr writes:

 On Mon, May 14, 2012 at 01:59:27PM +0200, Miklos Szeredi wrote:
 Louis-David Mitterrand l...@apartia.fr writes:
 
  On Mon, May 07, 2012 at 03:41:09PM +0200, Miklos Szeredi wrote:
  Louis-David Mitterrand l...@apartia.fr writes:
  
   Package: sshfs
   Version: 2.3-1
   Severity: normal
  
   Hi,
  
   When trying to save an attachement with mutt to a sshfs mounted
   filesystem I always get this error:
  
   fopen: File exists (errno = 17)
  
   If I try re-saving it mutt prompts me:
  
   File exists, (o)verwrite, (a)ppend, or (c)ancel?
  
   And overwriting works.
  
  Try -oworkaround=rename option.
 
  Same error.
 
  If that doesn't work please start sshfs with debugging enabled
  (-odebug,sshfs_debug) and post the resulting log.
 
  Here is the ouput:
 
  [...]
 
 Nothing to see there.  The file exists error comes from somewhere
 else.
 
 Can you attach strace to the mutt process and post the result as well?
 
   strace -f -o /tmp/strace -p `pidof mutt`

 Hi,

 Please find the strace attached.

Thanks.

Still I have no clues, the EEXIST error is not seen in any of the system
calls and I can't see fopen returning EEXIST for any reason.

Can you try ltrace as well?   Though I don't have high hopes of that
revealing anything...

Thanks,
Miklos



 29445 select(1, [0], NULL, NULL, {589, 87552}) = 1 (in [0], left {455, 
 254252})
 29445 read(0, \r, 1)  = 1
 29445 rt_sigaction(SIGINT, {0x46b270, [], SA_RESTORER|SA_RESTART, 
 0x7ff6fe7554f0}, NULL, 8) = 0
 29445 access(/mnt/zenon/Invitation projo.jpg, F_OK) = -1 ENOENT (No such 
 file or directory)
 29445 write(1, \33[4Ging...\33[K\33(B\33[m, 19) = 19
 29445 lstat(/mnt/zenon/.mutt8ispZ2, 0x7fff75664b10) = -1 ENOENT (No such 
 file or directory)
 29445 mkdir(/mnt/zenon/.mutt8ispZ2, 0700) = 0
 29445 open(/mnt/zenon/.mutt8ispZ2/Invitation projo.jpg, 
 O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW, 0600) = 7
 29445 close(7)  = 0
 29445 link(/mnt/zenon/.mutt8ispZ2/Invitation projo.jpg, 
 /mnt/zenon/Invitation projo.jpg) = 0
 29445 lstat(/mnt/zenon/.mutt8ispZ2/Invitation projo.jpg, 
 {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
 29445 lstat(/mnt/zenon/Invitation projo.jpg, {st_mode=S_IFREG|0600, 
 st_size=0, ...}) = 0
 29445 unlink(/mnt/zenon/.mutt8ispZ2/Invitation projo.jpg) = 0
 29445 rmdir(/mnt/zenon/.mutt8ispZ2)   = 0
 29445 open(/usr/share/locale/en_CA/LC_MESSAGES/libc.mo, O_RDONLY) = -1 
 ENOENT (No such file or directory)
 29445 open(/usr/share/locale/en/LC_MESSAGES/libc.mo, O_RDONLY) = -1 ENOENT 
 (No such file or directory)
 29445 write(1, \r\33[31mfopen: File exists (errno ..., 48) = 48
 29445 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
 29445 rt_sigaction(SIGCHLD, NULL, {0x46b260, [], 
 SA_RESTORER|SA_RESTART|SA_NOCLDSTOP, 0x7ff6fe7554f0}, 8) = 0
 29445 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
 29445 nanosleep({2, 0}, 0x7fff75665020) = 0
 29445 write(1, \rSave to file:\33[K \33(B\33[m, 24) = 24
 29445 write(1, /mnt/zenon/Invitation projo.jpg\33..., 37) = 37
 29445 rt_sigaction(SIGINT, {0x46b270, [], SA_RESTORER, 0x7ff6fe7554f0}, NULL, 
 8) = 0
 29445 select(1, [0], NULL, NULL, {600, 0} unfinished ...



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#670926: fopen: File exists (errno = 17) error when saving mutt attachment to sshfs

[Miklos Szeredi]

Louis-David Mitterrand l...@apartia.fr writes:

 On Mon, May 07, 2012 at 03:41:09PM +0200, Miklos Szeredi wrote:
 Louis-David Mitterrand l...@apartia.fr writes:
 
  Package: sshfs
  Version: 2.3-1
  Severity: normal
 
  Hi,
 
  When trying to save an attachement with mutt to a sshfs mounted
  filesystem I always get this error:
 
  fopen: File exists (errno = 17)
 
  If I try re-saving it mutt prompts me:
 
  File exists, (o)verwrite, (a)ppend, or (c)ancel?
 
  And overwriting works.
 
 Try -oworkaround=rename option.

 Same error.

 If that doesn't work please start sshfs with debugging enabled
 (-odebug,sshfs_debug) and post the resulting log.

 Here is the ouput:

 [...]

Nothing to see there.  The file exists error comes from somewhere
else.

Can you attach strace to the mutt process and post the result as well?

  strace -f -o /tmp/strace -p `pidof mutt`

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#670926: fopen: File exists (errno = 17) error when saving mutt attachment to sshfs

[Miklos Szeredi]

Louis-David Mitterrand l...@apartia.fr writes:

 Package: sshfs
 Version: 2.3-1
 Severity: normal

 Hi,

 When trying to save an attachement with mutt to a sshfs mounted
 filesystem I always get this error:

 fopen: File exists (errno = 17)

 If I try re-saving it mutt prompts me:

 File exists, (o)verwrite, (a)ppend, or (c)ancel?

 And overwriting works.

Try -oworkaround=rename option.

If that doesn't work please start sshfs with debugging enabled
(-odebug,sshfs_debug) and post the resulting log.

Thanks,
Miklos





 -- System Information:
 Debian Release: wheezy/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (499, 
 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.3.4-1-pyrrhus (SMP w/4 CPU cores)
 Locale: LANG=en_CA, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages sshfs depends on:
 ii  fuse2.8.7-2
 ii  libc6   2.13-31
 ii  libfuse22.8.7-2
 ii  libglib2.0-02.32.1-1
 ii  openssh-client  1:5.9p1-5

 sshfs recommends no packages.

 sshfs suggests no packages.

 -- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#594498: Patch for maintaining permissions

[Miklos Szeredi]

On Sat, Dec 3, 2011 at 2:19 PM, Maximiliano Curia
m...@gnuservers.com.ar wrote:
 I'm not exactly sure that the permissions should be handled this way, in fact 
 I
 would prefer a way to enforce permissions from the server side. But, if you
 are interested in this feature it might be worth applying the patch or trying
 to convince upstream (the authors) to accept it.

See this more recent discussion about the same issue:

  http://thread.gmane.org/gmane.comp.file-systems.fuse.sshfs/1207

So part of the problem can be solved on the server side.   The other
part (more fine grained control of permission bits on client side) is
still up for debate.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#645366: [fuse-devel] Hang and suspend failure after FUSE server killed (3.1-rc7)

[Miklos Szeredi]

Ben Hutchings b...@decadent.org.uk writes:

 On Fri, 2011-10-14 at 22:52 +, brian m. carlson wrote:
 Package: linux-2.6
 Version: 3.1.0~rc7-1~experimental.1
 Severity: normal
 
 This morning I was backing up my laptop to another computer via sshfs
 (and fuse).  The afio archiver was writing to this sshfs-mounted
 location.  I decided to abort the operation with Ctrl-C, which caused
 the sshfs mount to become unmounted; however, afio was apparently not
 affected by the SIGINT (probably because processes in disk IO are
 unkillable).
 
 Several hours later, I attempted to suspend my computer and it failed to
 do so. The kernel log (attached) indicated that the afio process from
 hours before was preventing the suspend.  Since processes waiting on
 disk IO are unkillable (IMO a bug) and the underlying device to which
 afio was writing was long gone, I was forced to reboot the machine in
 order to get it to suspend.  If I had not noticed that the machine had
 failed to suspend, it could have stayed running in my bag and seriously
 overheated.

 This seems to be a bug in FUSE.  Is this known about?  If not, could
 someone look into this?

It's a bug in the fuse-freezer interaction.  Yes, it is known.

Before suspending the machine all userspace task are frozen, which means
the freezer will wait until they exit the kernel (i.e. finish any system
calls).  If some task does not exit the kernel within a predefined time
then the freezer will give up and not let the machine be suspended.

Lets say task A is executing a system call that depends on task B to
finish.  In this case task B must not be frozen until task A is frozen
otherwise the suspend will be unsuccessful.

One often proposed solution is to try to order the freezing of userspace
tasks and leave task B's last.  The problem is that it's impossible to
know which task depends on which other task to be able to make progress.
For example the kernel could guess that sshfs is probably task B
type because it's reading and writing /dev/fuse.  But it's not going to
guess that a certain ssh process is also a task B.  This is also
complicated by the fact that a task could be task A and task B at
the same time...

Another suggested solution is to allow freezing of tasks that are
waiting for a fuse reply.  E.g:

  http://thread.gmane.org/gmane.linux.power-management.general/25926

However that would only fix a subset of the problems as described in
that thread.  Also it would disrupt the operation of the freezer in
cases where it actually needs the userspace task to be out of the kernel
(cgroup freezer).

We discussed this issue recently with Rafael Wysocki, the power
management maintainer, and came to the conclusion that the best solution
is to allow suspend to go ahead even if some tasks are not frozen.  But
we need to be careful about only allowing tasks to remain unfrozen if
they are known to be outside of driver code.  For example we can mark
the task safe to suspend if it's inside any well behaved filesystem
(block filesystems, fuse, NFS, etc).

One important implementation question is: how to do this marking of
safe tasks without adding too much runtime and maintenance overhead to
the kernel.

Ideas, patches are welcome.

Thanks,
Miklos


 Ben.

 [...]
 Oct 14 12:50:07 lakeview kernel: [129960.588174] INFO: task afio:22818 
 blocked for more than 120 seconds.
 Oct 14 12:50:07 lakeview kernel: [129960.588182] echo 0  
 /proc/sys/kernel/hung_task_timeout_secs disables this message.
 Oct 14 12:50:07 lakeview kernel: [129960.588188] afioD 
 880086e20300 0 22818  1 0x0084
 Oct 14 12:50:07 lakeview kernel: [129960.588199]  880086e20300 
 0086 8800065c1848 81037a71
 Oct 14 12:50:07 lakeview kernel: [129960.588210]  88003687f120 
 00012f00 881effd8 881effd8
 Oct 14 12:50:07 lakeview kernel: [129960.588220]  00012f00 
 880086e20300 00012f00 00012f00
 Oct 14 12:50:07 lakeview kernel: [129960.588231] Call Trace:
 Oct 14 12:50:07 lakeview kernel: [129960.588246]  [81037a71] ? 
 __wake_up_common+0x41/0x78
 Oct 14 12:50:07 lakeview kernel: [129960.588257]  [81344bb4] ? 
 _raw_spin_lock_irqsave+0x9/0x25
 Oct 14 12:50:07 lakeview kernel: [129960.588282]  [a0577ab3] ? 
 fuse_request_send+0x1a2/0x251 [fuse]
 Oct 14 12:50:07 lakeview kernel: [129960.588291]  [8106288b] ? 
 wake_up_bit+0x23/0x23
 Oct 14 12:50:07 lakeview kernel: [129960.588316]  [a057dd2f] ? 
 fuse_flush+0xca/0xfe [fuse]
 Oct 14 12:50:07 lakeview kernel: [129960.588322]  [810fcae7] ? 
 filp_close+0x3b/0x6a
 Oct 14 12:50:07 lakeview kernel: [129960.588326]  [810fcb9d] ? 
 sys_close+0x87/0xc4
 Oct 14 12:50:07 lakeview kernel: [129960.588331]  [81349e52] ? 
 system_call_fastpath+0x16/0x1b
 [...]



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact 

Bug#645366: [fuse-devel] Hang and suspend failure after FUSE server killed (3.1-rc7)

[Miklos Szeredi]

Ben Hutchings b...@decadent.org.uk writes:

 On Mon, 2011-10-17 at 16:22 +0200, Miklos Szeredi wrote:
 Ben Hutchings b...@decadent.org.uk writes:
 
  On Fri, 2011-10-14 at 22:52 +, brian m. carlson wrote:
  Package: linux-2.6
  Version: 3.1.0~rc7-1~experimental.1
  Severity: normal
  
  This morning I was backing up my laptop to another computer via sshfs
  (and fuse).  The afio archiver was writing to this sshfs-mounted
  location.  I decided to abort the operation with Ctrl-C, which caused
  the sshfs mount to become unmounted; however, afio was apparently not
  affected by the SIGINT (probably because processes in disk IO are
  unkillable).
  
  Several hours later, I attempted to suspend my computer and it failed to
  do so. The kernel log (attached) indicated that the afio process from
  hours before was preventing the suspend.  Since processes waiting on
  disk IO are unkillable (IMO a bug) and the underlying device to which
  afio was writing was long gone, I was forced to reboot the machine in
  order to get it to suspend.  If I had not noticed that the machine had
  failed to suspend, it could have stayed running in my bag and seriously
  overheated.
 
  This seems to be a bug in FUSE.  Is this known about?  If not, could
  someone look into this?
 
 It's a bug in the fuse-freezer interaction.  Yes, it is known.
 [...]

 But the FUSE server was already killed; shouldn't that cause outstanding
 requests to fail immediately?

Yes it should.

But my guess is that the server wasn't actually killed, otherwise the
archiver program would have just gotten ENOTCONN errors and exited.  The
fact that afio had hung means that sshfs also hung.  We can't prove or
disprove this without a process listing.

The reason for sshfs hanging could be due to one of the bugs that were
fixed in the sshfs-2.3 version.  E.g.:

* Fix cleanup when ssh connection is terminated.  This prevents
sshfs hanging when the server is rebooted, for example.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#640038: sshfs: cannot set timestamps of symbolic links

[Miklos Szeredi]

Dietrich Clauss d...@clauss.dyndns.org writes:

 Package: sshfs
 Version: 2.2-1
 Severity: normal

 When doing

 | touch -h some_link

 to a symbolic link located in an sshfs-mounted directory, it doesn't set
 the time stamp of the link.  Instead, sshfs follows the link on server
 side and it sets the time of the target file.  If the target doesn't
 exist, the touch command fails and it says

 | touch: setting times of `some_link': No such file or directory

 This also makes rsync fail when doing

 | rsync -au src/ dest/

 if src/ contains a symbolic link and dest/ is on sshfs.  rsync tries to
 preserve the times of the link and complains

 | rsync: failed to set times on dest/some_link: No such file or
 | directory (2)

 If the link points to an existing file on the server, then sshfs follows
 the link and rsync erroneously copies the time stamp of the link to the
 destination file on the server.

The SFTP protocol doesn't have a lsetstat operation and so this is not
possible to fix with current sftp servers.

We could add such an extension, I'll look into that.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#628735: /usr/bin/fusermount: Re: -u: /bin/umount: unrecognized option '--fake'

[Miklos Szeredi]

Ritesh Raj Sarraf r...@debian.org writes:

 Package: fuse
 Version: 2.8.5-2
 Followup-For: Bug #628735

 Not just that, from mount's table, the entry is not removed, where as
 the file system is unmounted.


 13:18:07 rrs@champaran:~$ df -h
 FilesystemSize  Used Avail Use% Mounted on
 /dev/mapper/LocalDisk-ROOT 110G   90G   18G  84% /
 tmpfs 1.5G   20K  1.5G   1% /lib/init/rw
 udev  1.5G  612K  1.5G   1% /dev
 tmpfs 1.5G  688K  1.5G   1% /dev/shm
 /dev/sda2 942M  127M  806M  14% /boot
 encfs 110G   90G   18G  84% /home/rrs/.crypt

 mount output:
 fusectl on /sys/fs/fuse/connections type fusectl (rw)
 encfs on /home/rrs/.crypt type fuse.encfs 
 (rw,nosuid,nodev,default_permissions,user=rrs)


 13:58:23 rrs@champaran:~$ fusermount -u ~/.crypt
 /bin/umount: unrecognized option '--fake'
 Usage: umount -h | -V
umount -a [-d] [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts]
umount [-d] [-f] [-r] [-n] [-v] special | node...

 13:58:40 rrs@champaran:~$ ls ~/.crypt


 -- System Information:
 Debian Release: wheezy/sid
   APT prefers testing
   APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages fuse depends on:
 ii  adduser   3.112+nmu2 add and remove users and groups
 ii  libc6 2.13-4 Embedded GNU C Library: Shared 
 lib
 ii  libfuse2  2.8.5-2Filesystem in Userspace (library)
 ii  sed   4.2.1-9The GNU sed stream editor
 ii  udev  167-3  /dev/ and hotplug management 
 daemo

Fuse should depend on util-linux = 2.18.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#628735: /usr/bin/fusermount: Re: -u: /bin/umount: unrecognized option '--fake'

[Miklos Szeredi]

Ritesh Raj Sarraf r...@debian.org writes:

 Miklos,

 That didn't help.

 On 06/02/2011 06:58 PM, Miklos Szeredi wrote:
 Fuse should depend on util-linux = 2.18.

 22:39:21 rrs@champaran:~$ encfs ~/.encrypt/ ~/.crypt/
 EncFS Password:
 22:39:29 rrs@champaran:~$ man fusermount
 22:39:34 rrs@champaran:~$ fusermount -u ~/.crypt
 /bin/umount: unrecognized option '--fake'
 Usage: umount -h | -V
umount -a [-d] [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts]
umount [-d] [-f] [-r] [-n] [-v] special | node...
 22:39:41 rrs@champaran:~$ apt-cache policy util-linux
 util-linux:
   Installed: 2.19.1-1
   Candidate: 2.19.1-1

That is really weird.

What does

  /bin/umount --version

say?

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613904: sshfs in combination with bind mounts and umount -f fails

[Miklos Szeredi]

On Fri, 18 Feb 2011, Johannes Martin wrote:
 Subject: sshfs in combination with bind mounts and umount -f fails
 Package: sshfs
 Version: 2.2-1
 Severity: normal
 
 *** Please type your report below this line ***
 
 If an sshfs file system is mounted, then mapped to a different location
 in the file system using a bind mount and then the bind mount is unmounted
 using the -f (force) flag (as is done for example in /etc/init.d/umountfs),
 the sshfs mount breaks:
 
 ---
 root:~/.ssh# mkdir -p /mnt/mp1
 root:~/.ssh# mkdir -p /mnt/mp2
 root:~/.ssh# sshfs localhost:/home /mnt/mp1
 root:~/.ssh# mount -o bind /mnt/mp1 /mnt/mp2
 root:~/.ssh# umount -f /mnt/mp2
 root:~/.ssh# ls /mnt/mp1
 ls: cannot access /mnt/mp1: Transport endpoint is not connected
 ---
 
 This is a problem when the bind mount is within a container
 (OpenVZ, lxc) and the container runs unmodified init scripts
 that unmount the bind mount with the -f flag. It leads to all
 other applications and containers to not be able to read
 from the sshfs mount any more.
 
 The problem also occurs with glusterfs, the it may be a problem
 in the fuse libraries or kernel driver.

Yep, this is how umount -f is supposed to work.  You'll get similar
behavior with other network filesystems: NFS, 9P, CEPH, CIFS, etc...

Unfortunately you cannot have an unmodified rc script in the
container in these cases.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613904: sshfs in combination with bind mounts and umount -f fails

[Miklos Szeredi]

On Fri, 18 Feb 2011, Johannes Martin wrote:
 Just verified, yes, it happens with CIFS, too.
 
 With NFS it works.

Sort of, if the server is temporarily down, then you'd see funny stuff
happening in the other mounts too.

 I don't believe this is how it is supposed to work. Why should an
 unmount on a bind mount affect other mounts?

Because they share a common super block.  Non forced unmounts indeed
don't affect other mounts since they only detach the mount from the
namespace and do not actually call into the filesystem in any way.

Forced umounts, on the other hand, do call into the filesystem and
instruct it to abort any outstanding requests so the umount can
proceed even if the server is dead.

I think it's pretty clear that you do not want this behavior for the
shutdown script in the container.  So just fix the script not to call
umount with the -f flag if it's running on non-native hardware.

 
 The docs say (man 2 umount):
 MNT_FORCE (since Linux 2.1.116)
Force  unmount  even  if busy.  This can cause data loss.  (Only
for NFS mounts.)
 
 So the -f flag should only make a difference if a filesystem is busy,
 and even then it should not affect other mount points.

That's your interpretation, but the fact is, Linux doesn't work that
way.

 I'm not unmounting the original mount and complain that the bind mount
 no longer works (that would in fact make sense with umount -f). It's the
 other way around: I'm unmounting something that happens to bind mount a
 directory lying on an sshfs file system to somewhere else and it causes
 the underlying mount to break (mount still lists the mount to be
 active, and so does /proc/mounts).

There's no distinction between original mount and bind mount in Linux.
From the kernel's point of view they are completely equal.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#593336: New version breaks encfs in some ways in combination with pam_encfs

[Miklos Szeredi]

On Wed, 06 Oct 2010, Mike Swanson wrote:
 Confirming the bug.  It's quite curious how this was allowed into the
 testing distribution after such a serious bug was already noted.  I also
 ended up with a system I could not log into; thank god for
 snapshot.debian.org, I was able to get 2.8.1-1.2 back and fix the
 regression.

This is a serious matter.  As upstream maintainer I'm very interested
why the new version breaks pam_encfs.

Could someone who can reproduce this please do a strace -f of the
login process to see where it hangs?

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#593336: New version breaks encfs in some ways in combination with pam_encfs

[Miklos Szeredi]

On Thu, 07 Oct 2010, Thomas Schwery wrote:
  Could someone who can reproduce this please do a strace -f of the
  login process to see where it hangs?
 
 You will find attached a trace ('strace -o login_trace -f login') of the
 login process for root (a normal user would fail with a Operation not
 permitted error).
 
 I had to interrupt the trace because after 10 minutes, nothing more
 happened ... The last line printed during login by encfs / pam-encfs is :
 (Interface.cpp:165) checking if nameio/block(3:0:1) implements
 nameio/block(3:0:0)

Thomas, thanks for the quick response.

It looks like --no-canonicalize isn't working 100% correctly in
mount(8).  Here's a patch to fix it.  Coud you please rebuild
util-linux with this patch to verify that it fixes the hang?

Karel, does this patch look OK?

Thanks,
Miklos
---

Subject: don't canonicalize spec with --no-canonicalize option

Spec was still canonicalized despite --no-canonicalize.  This
resulted in a hang during login with pam_encfs (Debian Bug#593336).

Signed-off-by: Miklos Szeredi mszer...@suse.cz
---
 mount/devname.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: util-linux-ng/mount/devname.c
===
--- util-linux-ng.orig/mount/devname.c  2009-02-23 13:33:02.0 +0100
+++ util-linux-ng/mount/devname.c   2010-10-07 15:54:48.0 +0200
@@ -8,7 +8,7 @@ spec_to_devname(const char *spec)
 {
if (!spec)
return NULL;
-   if (is_pseudo_fs(spec))
+   if (nocanonicalize || is_pseudo_fs(spec))
return xstrdup(spec);
return fsprobe_get_devname_by_spec(spec);
 }



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#593336: New version breaks encfs in some ways in combination with pam_encfs

[Miklos Szeredi]

reassign 593336 util-linux
retitle 593336 mount: missing nocanonicalize check breaks pam_encfs in 
combination with fuse-2.8.4
tags 593336 + patch
thanks

On Thu, 07 Oct 2010, Thomas Schwery wrote:
 I applied the patch you sent on my system to try, everything works
 fine now !

Great, thanks.  Reassigning to util-linux.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#571005: Also on 2.6.34

[Miklos Szeredi]

On Tue, 24 Aug 2010, Xavier Roche wrote:
 Also seen in a potentially (happened three times) reproductible way on a 
 2.6.34 (with grsecurity patches, but this is unrelated probably) ; sshfs 
 2.1-1
 
 Way to reproduce, apparently:
 
 (1) create a local storage file on a machine #1 with something like 20GB 
 of space (dd if=/dev/urandom of=/backup/space bs=1k count=2000)
 
 (2) remotely mount the directory where the file lies using sshfs on a 
 machine #2 (not on the same LAN, but with something like 20ms of lag) ; 
 the only specific option used is '-C' (compression)
 
 (3) losetup -e aes /dev/loop0 /mnt/remote-mount
 
 (4) mkfs -t ext2 /dev/loop0
 [ie. mkfs through the sshfs tunnel]
 
 The mkfs would hang randomly ; sometimes when creating the structures, 
 sometimes when finishing.

Please do echo t  /proc/sysrq-trigger and post the stack traces
from the dmesg output.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#584541: fuse-utils: encfs fails (via fusermount) if called from an encrypted dir

[Miklos Szeredi]

On Mon, 7 Jun 2010, Julian Gilbey wrote:
 On Mon, Jun 07, 2010 at 01:07:37PM +0200, Miklos Szeredi wrote:
  On Fri, 04 Jun 2010, Julian Gilbey wrote:
   The source of the problem appears to be in util/fusermount.c, lines
   599-605, where a check is performed to determine whether the current
   directory (.) is readable.  It is not at all clear to me why this
   should be necessary, as we are about to chdir to the mount point
   anyway.
  
  It's not clear whether this is needed or not.  If you look at
  mount_fuse() the original CWD is restored after do_mount() and before
  add_mount().  
  
  Currently add_mount() is called with the original working directory.
  If we didn't open the current directory then restoring it would not be
  possible.
 
 I'm unclear why the current directory needs to be restored.  After
 calling do_mount(), the current directory is restored, then there are
 a few cleanups and the program exits.  Nothing is done in the current
 directory.

add_mount() is called after do_mount().  This will execute /bin/mount
to add an entry to /etc/mtab.  This will be called with an absolute
path, so it should work with any CWD but it needs some careful thoght
to make sure it's OK in every respect.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#584541: fuse-utils: encfs fails (via fusermount) if called from an encrypted dir

[Miklos Szeredi]

On Fri, 04 Jun 2010, Julian Gilbey wrote:
 The source of the problem appears to be in util/fusermount.c, lines
 599-605, where a check is performed to determine whether the current
 directory (.) is readable.  It is not at all clear to me why this
 should be necessary, as we are about to chdir to the mount point
 anyway.

It's not clear whether this is needed or not.  If you look at
mount_fuse() the original CWD is restored after do_mount() and before
add_mount().  

Currently add_mount() is called with the original working directory.
If we didn't open the current directory then restoring it would not be
possible.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#571005: sshfs causes all processes that touch mountpoint to hang

[Miklos Szeredi]

On Mon, 22 Feb 2010, Greg Kochanski wrote:
 Package: sshfs
 Version: 2.2-1
 Severity: important
 
 
 I had mounted another computer via sshfs, the logged out.
 Next time I logged in, any process that touched the mountpoint
 would hang forever.ls mountpoint would hang, as would
 ls -l $HOME where mountpoint is in my home directory.
 This all started within the last few days.

Does killing the sshfs process fix the hang?

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#572222: sshfs: handle IPv6 host addresses

[Miklos Szeredi]

On Tue, 02 Mar 2010, Giorgos Pallas wrote:
 I guess that sshfs could also handle a command of the form:
 sshfs 2001:648:2800:13:21fa:d05f:fea4:b155:/media/ /media/myserver
 
 or something like that in order for the colons not to get confused...
 
 See also:
 http://old.nabble.com/sshfs-and-IPv6-numerical-addresses-td19586406.html

So, does the following work?

  sshfs [2001:648:2800:13:21fa:d05f:fea4:b155]:/media/ /media/myserver

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#565229: sshfs mount makes system freeze/hibernation/resume not working

[Miklos Szeredi]

On Thu, 14 Jan 2010, Witold Baryluk wrote:
 Package: sshfs
 Version: 2.2-1
 Severity: normal
 
 It is simple to reproduce:
 1. mount something using sshfs
 2. suspend machine
 
 suspending will not work, and system will resume immieditly.

Ack, problems with sshfs vs. suspend are known.  There's no fix yet,
it's difficult to fix properly.  Workaround is to unmount sshfs
filesystems before suspend.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#537786: sshfs: umask option does not work as expected

[Miklos Szeredi]

On Tue, 21 Jul 2009, Sam Hocevar wrote:
 When using eg. umask=002, instead of using the information to control
 permissions of new files, sshfs makes all remote files appear as
 executable locally.

This is how this option is supposed to work.  The README in the fuse
package says about the 'umask' option:

umask=M

  Override the permission bits in 'st_mode' set by the filesystem.
  The resulting permission bits are the ones missing from the given
  umask value.  The value is given in octal representation.

This may be confusing, and so it probably should be explicitly
mentioned in the sshfs man page.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#536665: option to hard-block while network connection is down

[Miklos Szeredi]

On Sun, 12 Jul 2009, martin f krafft wrote:
 Package: sshfs
 Version: 2.2-1
 Severity: wishlist
 
 It would be nice to have an option like NFS 'hard', which would
 require 'reconnect' and basically causes all filesystem operations
 to block until the connection to the remote is back. Right now, if
 a connection is lost and cannot be re-established, there's an I/O error:

It's not as simple as that.  NFSv3 is a stateless protocol, it doesn't
associate state with open files.  SFTP on the other hand has stateful
opens.  Yes, we could try to re-open files on reconnection but that
will not always succeed (permissions changed, file removed, etc).

To summarize, sshfs will never match NFS in correctness, it will
always remain a somewhat hackish (but still useful) network
filesystem.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#536665: option to hard-block while network connection is down

[Miklos Szeredi]

On Thu, 16 Jul 2009, martin f krafft wrote:
 also sprach Miklos Szeredi mik...@szeredi.hu [2009.07.16.2203 +0200]:
  It's not as simple as that.  NFSv3 is a stateless protocol, it doesn't
  associate state with open files.  SFTP on the other hand has stateful
  opens.  Yes, we could try to re-open files on reconnection but that
  will not always succeed (permissions changed, file removed, etc).
 
 Good explanation. But couldn't the errors be postponed until then,
 so that iff the file can be reopened, then stuff just moves on?

Sure.  Someone just needs to do the coding...

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#535333: sshfs checks argument list in wrong order

[Miklos Szeredi]

On Wed, 01 Jul 2009, Greg Kochanski wrote:
 Package: sshfs
 Version: 2.2-1
 Severity: minor
 
 
 If I run sshfs and forget to type a mountpoint, sshfs
 doesn't realize this until I've already logged into the
 host computer. It ought to do the log-in last.
 
 First check should be Are there enough arguments?
 Second check should be Does the mountpoint exist?
 Then, finally, the login should happen.

I committed a fix for this to CVS.

Thanks for the bug report.

Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#535343: sshfs: insufficient command line checking

[Miklos Szeredi]

On Wed, 01 Jul 2009, Greg Kochanski wrote:
 Package: sshfs
 Version: 2.2-1
 Severity: minor
 
 
 
 This is a bug in error reporting, or really
 a failure to check for a user error.
 
 
 If you run
 sshfs -o nonempty host:dir mountpoint
 and mountpoint is a normal file, created via
  mountpoint
 sshf reports success but nothing is mounted on
 mountpoint.   In fact, any access of mountpoint thereafter
 gives Input/Output errors.

Fixed this one as well in CVS.

After upgrading to next release (sshfs-2.3) this can be closed.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#534727: fuse-utils: fusermount should not silently ignore command line arguments

[Miklos Szeredi]

On Fri, 26 Jun 2009, Sebastian Harl wrote:
 fusermount, when called with multiple mount-points, silently ignores the
 further arguments. Instead it should imho print a warning message.

Thanks, applied with a modification that fusermount exits with an
error if too many mountpoint arguments are specified.

Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#531329: undefined reference to `fuse_reply_bmap'

[Miklos Szeredi]

Goswin, thanks for the report.  Committed the following patch to the
bugfix branch:

Index: lib/fuse_versionscript
===
RCS file: /cvsroot/fuse/fuse/lib/fuse_versionscript,v
retrieving revision 1.24
diff -u -r1.24 fuse_versionscript
--- lib/fuse_versionscript  12 Dec 2007 11:53:34 -  1.24
+++ lib/fuse_versionscript  16 Jun 2009 14:32:57 -
@@ -151,7 +151,12 @@
fuse_register_module;
fuse_reply_iov;
fuse_version;
+} FUSE_2.6;
+
+FUSE_2.7.5 {
+   global:
+   fuse_reply_bmap;
 
local:
*;
-} FUSE_2.6;
+} FUSE_2.7;



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#530507: sshfs hangs when trying to access /proc of another host

[Miklos Szeredi]

On Tue, 26 May 2009, Ritesh Raj Sarraf wrote:
 Still, is sshfs/fuse still involved for a bug here ?

As a wild guess I would say this is caused by sftp-server being single
threaded.  So no, fuse or sshfs is probably not invloved in this bug.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#515113: sshfs: Doesn't give correct information about disk usage

[Miklos Szeredi]

This is fixed in sshfs-2.1 (which can be found in lenny).

The ssh package on the server also needs to be upgraded to at least
OpenSSH-5.0 to be able to get the disk usage data.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#510357: umask option does not actually work like a mask

[Miklos Szeredi]

On Wed, 31 Dec 2008, Michael Goetze wrote:
 Package: libfuse2
 Version: 2.7.4-1.1
 
 When mounting something with curlftpfs 0.9.1-3+b2 and passing -o 
 uid=1000,umask=077 to libfuse2, I can only see files of mode 700. If I 
 only pass -o uid=1000, I get lots of files with modes like 644, i.e. 
 if you actually applied a umask of 077 to these they would be 600, not 700.

Hmm.  I'm not sure what the original intention was, but I think it may
have been what the current behavior is.  The short description of the
option in the help output is:

-o umask=M  set file permissions (octal)

and the long description in the README:

umask=M

  Override the permission bits in 'st_mode' set by the filesystem.
  The resulting permission bits are the ones missing from the given
  umask value.  The value is given in octal representation.

Both seem to imply that the original file mode is ignored.  Yes this
is inconsistent with the normal notion of umask, and the option
should've perhaps been called mode (and bits reversed).  But now I'm
inclined to leave things as is, otherwise filesystems could break.

Thanks,
Miklos




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509525: libfuse2: FUSE blocks write access for root

[Miklos Szeredi]

allow_root works fine for me with the latest version of fuse.

Can you please provide some more details:

 - how are you starting curlftpfs?
 - what is the error message printed if allow_root is used?

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#502579: fuse: together with sshfs does not mount locations with ',' in the name

[Miklos Szeredi]

This bug has already been fixed in sshfs-2.2 and fuse CVS.

But thanks for the patches anyway!



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#495318: [sshfs] Bug#495318: sshfs: Hangs on write to a file, blocks applications

[Miklos Szeredi]

On Sat, 16 Aug 2008, Adolf Winterer wrote:
 Additional tests:
 scp to another computer with a roughly identical installation succeeds! So we 
 have a problem with an older / other versions of ssh?
 
 The destination computer is a SUSE 10.1 with openssh-4.2p1-18.12 .

Can you try doing strace on the sftp-server process on the
destination?

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#430225: sshfs: prevents some ssh_config options from being used

[Miklos Szeredi]

 I've being testing sshfs and checking its code for version 1.9.1.
 I haven't seen in the code any way to use some of the ssh_config
 options. In fact, the option ControlPath that the author of the patch
 (Fabian Pietsch) tries to fix can not be used.
 
 Also, none of the provided patches is applied, so I can not understand
 why you closed this bug.
 
 So, please, tell me if this can be done and I've not been able to do it,
 or the bug just can not be closed.

Thanks for the report and forward.

I've committed two fixes into upstream CVS:

 1) add missing options

 2) allow a command with parameters in '-ossh_command=CMD' option

I'll be releasing a new sshfs version soon.

Miklos



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#472697: fuse-utils: required binary ulockmgr_server not packaged

[Miklos Szeredi]

reassign 472697 encfs
thanks

 fuse-utils does not package ulockmgr_server which is required for
 instance for handling mandatory locks as used by openoffice

Encfs's use of ulockmgr was actually a mistake.  So this probably
doesn't need to be fixed in the fuse package.

Miklos



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#467613: sshfs denies overwriting existing files

[Miklos Szeredi]

 The subject says it all. Do:
 
 touch x
 touch y
 mv -f x y
 
 and you will get Permission denied.
 the bug was known (Bug#318078) and still present.

Pleas use the '-oworkaround=rename' option.

This is being worked on, but it requires changes to the SFTP protocol
and the sftp-server, which is in the OpenSSH project.  So this is not
fixable in sshfs alone.

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#458167: crash when mount to a remote slower device

[Miklos Szeredi]

Thank you for the detailed bug report.

This looks like a known sftp-server bug, for which a workaround has
been added to sshfs-1.8.  AFAIK it has also been properly fixed in a
recent OpenSSH release.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451633: exim4-config: whitelist should override SPF and DNSBL checks

[Miklos Szeredi]

Package: exim4-config
Version: 4.63-17
Severity: normal

A host added to local_host_whitelist should prevent SPF and DNSBL
checks to be made.

Currently it is impossible for an SPF enabled host to whitelist
forwarders which do not rewrite the sender address.  See:

  http://www.openspf.org/FAQ/Forwarding

-- Package-specific info:
Exim version 4.63 #1 built 20-Jan-2007 10:40:39
Copyright (c) University of Cambridge 2006
Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (September  6, 2005)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dsearch nis 
nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
[snipped]

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20-rc7
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages exim4-config depends on:
ii  adduser   3.102  Add and remove users and groups
ii  debconf [debconf-2.0] 1.5.11 Debian configuration management sy

exim4-config recommends no packages.

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#375521: Not fixed

[Miklos Szeredi]

 sshfs#klecker:books  1000G 0 1000G   0% /home/frankie/books
 
 Well, it is not truly fixed. At least reports 0 size available
 but it would be more correct not reporting any valid size, i.e.
 
 sshfs#klecker:books  0 0 0   0% /home/frankie/books

That causes problems with some programs which refuse to write a file
if zero space is available.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#430225: -o ForwardAgent=yes fails

[Miklos Szeredi]

 I'd like my sshfs mount forward authentication but:
 
 % sshfs -o ForwardAgent=yes my.remote.host:/home/ldm /mnt/zenon 
 fuse: unknown option `ForwardAgent=yes' 

Maybe I don't correctly understand what ForwardAgent does, but in my
world view it doesn't make any sense for sshfs, only for plain ssh.

Can you explain why you would need authentication forwarding with
sshfs?

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#428405: sshfs mount with remote uid and gid

[Miklos Szeredi]

 sshfs mount with remote uid and gid on the local filesystem.

Sshfs has no idea about the mapping between the remode user/group IDs
and the local ones.

If this is problematic, you can work around it by either using the 
'-o idmap=user' option or the '-o uid=X,gid=Y' options.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427518: fuse-utils: kernel oops when reinstalling

[Miklos Szeredi]

reassign 427518 kernel
tags 427518 patch
thanks

 running apt-get --reinstall install fuse-utils causes a kernel oops
 I can reproduce it when I'm mounting a remote partition over ssh using sshfs.
 I can also reproduce it when nvidia is loaded and after rmmod nvidia
 
 sshfs version 1.7-2
 Linux vader 2.6.18-4-486 #1 Mon Mar 26 16:39:10 UTC 2007 i686 GNU/Linux

This is fixed in 2.6.20.  Somehow it missed the -stable kernels.

Patch is available here:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ff79544754631cf3d237ff47b7d0e7ab2d211fcf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#424871: libfuse-dev: Typo in fuse.h

[Miklos Szeredi]

 Should the comment in fuse.h for the utime callback read:
 Deprecated, use utimens() instead. instead of:
 Deprecated, use utimes() instead. ?
 
 There is no utimes() callback.

Right.  Fixed in upstream.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#423238: Memory leak in fuse

[Miklos Szeredi]

 There seems to be a memory leak somewhere in fuse.  To reproduce:
 
 % cp /usr/share/doc/libfuse-dev/examples/fusexmp.c .
 % (remove reference to config.h)
 % gcc -Wall `pkg-config fuse --cflags --libs` fusexmp.c -o fusexmp
 % mkdir test
 % ./fusexmp test
 % du -ms test 
 % watch ps -C fusexmp -o pid,rss,cmd
 
 The resident size of fusexmp continues to grow.  Not sure if fuse is
 caching something on purpose, or if this is a real leak.

Yes, fuse is caching nodes and so a growing RSS is normal.  You can
check with valgrind, that that there's in fact no memory leak in this
case.

 This isn't unique to fusexmp either.  The fusexmp_fh example, and sshfs
 also do this.
 
 I did find one place where if fuse_do_getattr failed then memory
 wouldn't be freed, but this didn't fix my problem.
 
 --- fuse-2.6.3.orig/lib/fuse.c
 +++ fuse-2.6.3/lib/fuse.c
 @@ -682,10 +682,10 @@
  break;
 
  res = fuse_do_getattr(f, req, newpath, buf);
 -if (res != 0)
 -break;
  free(newpath);
  newpath = NULL;
 +if (res != 0)
 +break;
  } while(--failctr);
 
  return newpath;

This patch is definitely wrong.  When we break out of the loop, the
newpath needs to be set, and is actually freed in hide_node().
Freeing it within the loop would break the unlink while open
semantics.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#415107: Bug also triggered when using smbnetfs

[Miklos Szeredi]

reassign 415107 fusesmb
thanks

Sorry, forgot to reassign it back...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#415107: Bug also triggered when using smbnetfs

[Miklos Szeredi]

Maybe bug in libsmbclient?  Or both packages misuse libsmbclient in
the same way.

This is very unlikly to be a libfuse bug.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#417834: mount.fuse cannot handle spaces in paths

[Miklos Szeredi]

 Package: fuse-utils
 Version: 2.6.3-1
 
 I would like this command to work:
 
 mount.fuse sshfs#'[EMAIL PROTECTED]:/cygdrive/c/Documents and 
 Settings/Testuser/My Documents' /mnt/remote-testuser -o 
 noexec,uid=1000,umask=0,allow_other,port=50022,reconnect
 
 Please change the last line of /sbin/mount.fuse to:
 
 ${FSTYPE} ${MOUNTPATH} ${MOUNTPOINT} ${OPTIONS}

Thanks.  Committed on the bugfix branch.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#417945: fuse-utils: tiger complains about mount point /sys/fs/fuse/connections/

[Miklos Szeredi]

 I received this warning message in an e-mail from cron/tiger:
 
 --CONFIG-- [con010c] Filesystem 'fusectl' used by 'none' is not recognised as 
 a local filesystem
 
 This is caused by this mount point:
 
 # grep fuse /proc/mounts
 none /sys/fs/fuse/connections fusectl rw 0 0
 
 where none should be replaced by fusectl (as in other virtual
 filesystems such as usbfs or devpts).
 
 Therefore I propose that in /etc/init.d/fuse you replace:
 
 mount -t fusectl none $MOUNTPOINT /dev/null 21 || \
 
 with:
 
 mount -t fusectl fusectl $MOUNTPOINT /dev/null 21 || \

That makes sense.

Fixed in upstream.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#353968: rsync still doesn't work with sshfs

[Miklos Szeredi]

 rsync: rename /mnt/space_home/public_html/music/.index.html.PhNWaZ -
 index.html: Operation not permitted (1)

Are you using the -oworkaround=rename option?

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#415118: sshfs: Unreadable relative symlinks

[Miklos Szeredi]

 Relative symlinks, for example symlinks to files in the same directory are
 not readable. I get an error Operation not permitted.
 
 Example:
 
 [EMAIL PROTECTED]:~$ ssh s touch a
 [EMAIL PROTECTED]:~$ ssh s ln -s a b
 [EMAIL PROTECTED]:~$ ssh s ls -l b
 lrwxrwxrwx   1 cek  gi 1 Mar 16 08:25 b - a
 [EMAIL PROTECTED]:~$ mkdir s
 [EMAIL PROTECTED]:~$ sshfs s: s
 [EMAIL PROTECTED]:~$ ls -l s/b
 ls: cannot read symbolic link s/b: Operation not permitted
 lrwxrwxrwx 1 4627 4600 1 2007-03-16 08:25 s/b
 
 Since they are relative they should be readable.
 
 Mounting with -o workaround all doesn't fix this.

My guess is that this is an old/different sftp-server than the usual
one supplied in OpenSSH.  Can please send the output of:

  sshfs -odebug,sshfs_debug,loglevel=debug s: s 
  ls -l s/b

Thanks,
Miklos



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#318078: reopen

[Miklos Szeredi]

 The bug still occurs in version 1.7-2 of the package:
 
 $ touch x y
 $ mv -f x y
 mv: cannot move `x' to `y': Operation not permitted

This is a FAQ dammit!

   mv fails with Operation not permitted.
   
   Use -o workaround=rename (requires sshfs version = 1.3).

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#415118: sshfs: Unreadable relative symlinks

[Miklos Szeredi]

 Yes, the machine whose fs I'm trying to mount is a Sun, 
 the SSH server returns: SSH-2.0-Sun_SSH_1.0.1.
 
[...]
 Server version: 2
[...]
 Apart from symbolic links all other operations seem to work
 with this server with sshfs.

SFTP version 2 doesn't support SYMLINK and READLINK.  Basically this
is the only difference between versions 2 and 3.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#413394: fuse-utils: /etc/init.d script has broken start/stop messages

[Miklos Szeredi]

 Here is a simple patch which makes the simple default case of
 loading/unloading work better.

This wasn't my fault after all: I thought debian included the original
init script supplied in the fuse package, but it was modified for some
reason.

So this is a packaging issue, and I don't have to do anything ;)

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#411143: init script fails to unload kernel module

[Miklos Szeredi]

 I just upgraded the fuse-utils package, and got bitten by this, although
 indirectly. It went like this:
 * prerm called invoke-rc.d fuse-utils stop. The module removal
 failed, since a fuse FS was still mounted. The fusectl pseudo-FS got
 successfully unmounted.
 * postint called invoke-rc.d fuse-utils start. Re-mounting the fusectl
 pseudo-FS while a fuse FS was still mounted triggered a bug in the
 kernel. I got a nice stack trace and mount blocked forever. Drama ensued.
 
 This is a kernel bug so it's not directly related to this package. So
 what's my point ? I don't know much about the Debian policy, but I don't
 think that the stop argument of the init script should do anything.
 Messing with the kernel module and the pseudo-FS after the system boot
 introduces more problems than it solves. BTW, this is the approach of
 the nfs-common package: its init script does not remove the nfs kernel
 module when called with the stop argument.

Yeah, although normally after deinstalling the package you'd want to
return to the state prior to installing it, which is no module loaded
and control filesystem not mounted.

But I agree that this is really unfortunate, given this kernel bug :(

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#413403: fuse-utils: mount.fuse only works with bash

[Miklos Szeredi]

 It is impossible to mount a fuse filesystem from fstab if dash is used
 as standard shell.
 Example:
 
 |[EMAIL PROTECTED] ~ # mount /srv/ftp 
 |/sbin/mount.fuse: 23: function: not found
 |-e mount.fuse# [EMAIL PROTECTED]:/
 |exit: 26: Illegal number: /srv/ftp
 
 After changing the standard shell back to bash, it works without
 problems.

Thanks.  Added fix to CVS on the bugfix branch.

Fuse-2.7 will have a revamped mount.fuse written in C instead of
sh-script.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#413394: fuse-utils: /etc/init.d script has broken start/stop messages

[Miklos Szeredi]

severity 413394 wishlist
thanks

 The start-stop messages are not working:
 
 [EMAIL PROTECTED] /etc/init.d /etc/init.d/fuse-utils start
 Starting FUSE: :.
 [EMAIL PROTECTED] /etc/init.d /etc/init.d/fuse-utils stop
 Stopping FUSE: :.
 
 Without knowing or looking at the policy manual, it should probably work more
 like for eksample openssh-server, meaning it would output
 
 [EMAIL PROTECTED] /etc/init.d /etc/init.d/fuse-utils start
 Loading filesystem in userspace module: FUSE
 
 when starting, and then add a . to the end upon success.
 
 You might want to add a separate message for already loaded to the
 start command, and a not loaded message to the stop command.

Lowering severity to wishlist, as this is just an aesthetic problem,
isn't it?

Will add a singing dancing LSB compatible init script to fuse-2.7

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#413394: fuse-utils: /etc/init.d script has broken start/stop messages

[Miklos Szeredi]

  Lowering severity to wishlist, as this is just an aesthetic problem,
  isn't it?
 
  Will add a singing dancing LSB compatible init script to fuse-2.7
 
  Thanks,
  Miklos
 
 As it is now, I thought that FUSE failed to start because it printed
 out an empty message after the starting: part.
 
 Now, it wont bother me because I know it does work. But it is going to
 confuse other people.
 
 So since it can actually be quickly changed to print a saner message
 (ignoring the format for LSB and other niceties), I think this would
 be a nice thing to have. This change would take fewer characters than
 was in your reply email :).

Sure, bit it would take 10 times more thinking, which is the real
bottleneck here ;)

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#365541: Problem tracked down

[Miklos Szeredi]

 I tracked the problem down. Depending on how you look at it, it is a
 bug in openssh's sftp or in sshfs.
 
 The problem is that when sending a file data, sshfs will just keep
 sending without waiting for the server to catch up. This does not need
 to be a problem, as the sftp server should just stop receiving TCP
 packets when the buffers are full, causing TCP resends and
 automatically slowing down the sending.
 
 However, the openssh sftp server loop (openssh:sftp-server.c) will
 just keep trying to read from stdin. It will read from stdin to its
 input buffer at most once per loop, and dispatch at most one sftp
 packet per loop. But as each read from stdin can read up to 8 sftp
 packets into the input buffer then the input buffer risks running out
 of space. When it runs out of space then it just kills itself
 (openssh:buffer.c:buffer_append_space).
 
 I note that the openssh sftp client has a mechanism to limit the
 number of unanswered requests, which probably means unlike sshfs, it
 is not affected.
 
 I found that a reliable way to trigger this bug was to start a
 parallel process which hogs the disk, causing the consuming sftp
 server loop to slow down.
 -sshfs-mount localhost:/tmp test
 -ionice -c1 cp large_file /tmp/deleteme
 -dd if=/dev/zero of=test/deleteme2
 
 The error I get is
 dd: writing to `test/deleteme2': Input/output error
 dd: closing output file `test/deleteme2': Transport endpoint is not connected
 
 It is somewhat a matter of opinion, but I would say that it is openssh
 which should be fixed. If I look at

Great bug hunting! :)

The Transport endpoint is not connected error means, that sshfs
crashed, which it should not do even with a buggy sftp server.  Also
it's probably not too hard to work around this in sshfs as well.  I'll
have a look at these.

But you're right, that there's definitely something wrong with the
server as well, which should also be fixed.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#365541: Problem tracked down

[Miklos Szeredi]

This patch works around the sftp-server bug in sshfs:

Index: sshfs.c
===
RCS file: /cvsroot/fuse/sshfs/sshfs.c,v
retrieving revision 1.80
diff -u -r1.80 sshfs.c
--- sshfs.c 20 Dec 2006 17:48:08 -  1.80
+++ sshfs.c 19 Feb 2007 15:13:38 -
@@ -124,6 +124,7 @@
 struct timeval start;
 void *data;
 request_func end_func;
+size_t len;
 struct list_head list;
 };
 
@@ -186,6 +187,9 @@
 unsigned blksize;
 char *progname;
 long modifver;
+unsigned outstanding_len;
+unsigned max_outstanding_len;
+pthread_cond_t outstanding_cond;
 };
 
 static struct sshfs sshfs;
@@ -958,8 +966,13 @@
  GUINT_TO_POINTER(id));
 if (req == NULL)
 fprintf(stderr, request %i not found\n, id);
-else
+else {
+int was_over = sshfs.outstanding_len  sshfs.max_outstanding_len;
+sshfs.outstanding_len -= req-len;
+if (was_over  sshfs.outstanding_len = sshfs.max_outstanding_len)
+pthread_cond_broadcast(sshfs.outstanding_cond);
 g_hash_table_remove(sshfs.reqtab, GUINT_TO_POINTER(id));
+}
 pthread_mutex_unlock(sshfs.lock);
 if (req != NULL) {
 struct timeval now;
@@ -1353,6 +1366,11 @@
 pthread_mutex_unlock(sshfs.lock);
 goto out;
 }
+req-len = iov_length(iov, count) + 9;
+sshfs.outstanding_len += req-len;
+while (sshfs.outstanding_len  sshfs.max_outstanding_len)
+pthread_cond_wait(sshfs.outstanding_cond, sshfs.lock);
+
 g_hash_table_insert(sshfs.reqtab, GUINT_TO_POINTER(id), req);
 gettimeofday(req-start, NULL);
 DEBUG([%05i] %s\n, id, type_name(type));
@@ -2356,6 +2374,7 @@
 {
 pthread_mutex_init(sshfs.lock, NULL);
 pthread_mutex_init(sshfs.lock_write, NULL);
+pthread_cond_init(sshfs.outstanding_cond, NULL);
 sshfs.reqtab = g_hash_table_new(NULL, NULL);
 if (!sshfs.reqtab) {
 fprintf(stderr, failed to create hash table\n);
@@ -2580,6 +2601,7 @@
 
 sshfs.blksize = 4096;
 sshfs.max_read = 65536;
+sshfs.max_outstanding_len = 8388608; /* buggy sftp-server in OpenSSH */
 sshfs.nodelay_workaround = 1;
 sshfs.nodelaysrv_workaround = 1;
 sshfs.rename_workaround = 0;


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#409554: Crash with sshfs: fuse.c:1663: fuse_release: Assertion `node-open_count 0' failed.

[Miklos Szeredi]

reassign 409554 fuse
thanks

This is a regression introduced in 2.6.2.

Will release 2.6.3 in a couple of days with a fix.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#409253: FTBFS: error: macro fuse_main requires 4 arguments, but only 3 given

[Miklos Szeredi]

 Package: sshfs-fuse
 Version: 1.6-1
 Severity: serious
 
  Automatic build of sshfs-fuse_1.6-1 on em64t by sbuild/amd64 0.52
 ...
  make[2]: Entering directory `/build/tbm/sshfs-fuse-1.6'
  if x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.  -D_REENTRANT 
  -DFUSE_USE_VERSION=26 -DLIBDIR=\/usr/lib\  -D_FILE_OFFSET_BITS=64 
  -I/usr/include/fuse -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   
  -Wall -g -O2 -Wall -W -Icompat -MT sshfs-sshfs.o -MD -MP -MF 
  .deps/sshfs-sshfs.Tpo -c -o sshfs-sshfs.o `test -f 'sshfs.c' || echo 
  './'`sshfs.c; \
  then mv -f .deps/sshfs-sshfs.Tpo .deps/sshfs-sshfs.Po; else rm -f 
  .deps/sshfs-sshfs.Tpo; exit 1; fi
  sshfs.c:2352:65: error: macro fuse_main requires 4 arguments, but only 3 
  given
  sshfs.c: In function 'sshfs_opt_proc':
  sshfs.c:2352: error: 'fuse_main' undeclared (first use in this function)
  sshfs.c:2352: error: (Each undeclared identifier is reported only once
  sshfs.c:2352: error: for each function it appears in.)
  sshfs.c:2359:65: error: macro fuse_main requires 4 arguments, but only 3 
  given
  sshfs.c:2514:66: error: macro fuse_main requires 4 arguments, but only 3 
  given
  sshfs.c: In function 'main':
  sshfs.c:2514: error: 'fuse_main' undeclared (first use in this function)
  make[2]: *** [sshfs-sshfs.o] Error 1

Mea culpa.  Please upgrade to 1.7

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#409072: /usr/bin/X: X crashes with symbol lookup error: /usr/X11R6/lib/libXfont.so.1: undefined symbol: FT_Init_FreeType

[Miklos Szeredi]

Package: x11-common
Version: 1:7.1.0-11
Severity: important
File: /usr/bin/X


The X server crashes hard, console text mode is not restored.  There's
nothing in Xorg.0.log to indicate a crash.

The last line belonging to the session in /var/log/kdm.log is:

/usr/X11R6/bin/X: symbol lookup error: /usr/X11R6/lib/libXfont.so.1: undefined 
symbol: FT_Init_FreeType

I can trigger it reliably by loading http://freshmeat.net/projects/linux
into Opera.

This started happening after upgrading to Xorg.

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.4
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages x11-common depends on:
ii  debconf [debconf-2.0] 1.5.11 Debian configuration management sy
ii  debianutils   2.17   Miscellaneous utilities specific t
ii  lsb-base  3.1-22 Linux Standard Base 3.1 init scrip

x11-common recommends no packages.

-- debconf information:
  x11-common/xwrapper/allowed_users: Console Users Only
  x11-common/xwrapper/actual_allowed_users: console
  x11-common/xwrapper/nice_value/error:
* x11-common/upgrade_issues:
  x11-common/xwrapper/nice_value: -10
* x11-common/x11r6_bin_not_empty:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#409072: /usr/bin/X: X crashes with symbol lookup error: /usr/X11R6/lib/libXfont.so.1: undefined symbol: FT_Init_FreeType

[Miklos Szeredi]

  The X server crashes hard, console text mode is not restored.  There's
  nothing in Xorg.0.log to indicate a crash.
  
  The last line belonging to the session in /var/log/kdm.log is:
  
  /usr/X11R6/bin/X: symbol lookup error: /usr/X11R6/lib/libXfont.so.1: 
  undefined symbol: FT_Init_FreeType
  
 why do you still have a /usr/X11R6/lib/libXfont.so.1?

$ ls -al /usr/X11R6/lib/libXfont.so.1
lrwxrwxrwx 1 root root 15 Jun  1  2004 /usr/X11R6/lib/libXfont.so.1 - 
libXfont.so.1.5
$ dpkg -S /usr/X11R6/lib/libXfont.so.1.5
dpkg: /usr/X11R6/lib/libXfont.so.1.5 not found.

Looks like a non-deb installation, though I can't remember when or why
I might have done that.

Removing it resolves the issue, so it was my fault.  Sorry for the
noise.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#402876: [fuse-devel] FUSE not working on ARM? Hangs during stat64

[Miklos Szeredi]

  Can you please try the out-of-tree kernel module from the fuse-2.6.x
  package (use 'configure --enable-kernel-module).  That contains a
  workaround for a bug in the ARM architecture code.
 
 Do you think it would it be easily possible to apply this workaround
 to the Debian kernel?

Yes, it should apply without problems.  Alternatively you can apply
RMK's patches which add flush_anon_page() support to ARM.  The later
should also fix other problems unrelated to fuse.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#404904: Bug#404834: linux-image-2.6.18-3-sparc64: Kernel unaligned access kills at least sshfs (and may make USB unreliable)

[Miklos Szeredi]

Thanks.  I believe I undestand now: the buffer reserved for the cmsg
is itself unaligned because it's a char array.  It should be an array
of size_t, which will have the required alignment.

When you have time, can you please try out this patch?  The old patch
shouldn't be needed.  If it still breaks, then please send a new
backtrace with debug information, since it may be a different problem.

Thanks,
Miklos

Index: lib/mount.c
===
RCS file: /cvsroot/fuse/fuse/lib/mount.c,v
retrieving revision 1.33
diff -u -r1.33 mount.c
--- lib/mount.c 4 Dec 2006 12:45:19 -   1.33
+++ lib/mount.c 30 Dec 2006 13:52:43 -
@@ -151,7 +151,7 @@
 struct iovec iov;
 char buf[1];
 int rv;
-char ccmsg[CMSG_SPACE(sizeof(int))];
+size_t ccmsg[CMSG_SPACE(sizeof(int))/sizeof(size_t)];
 struct cmsghdr *cmsg;
 
 iov.iov_base = buf;


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#404904: Bug#404834: linux-image-2.6.18-3-sparc64: Kernel unaligned access kills at least sshfs (and may make USB unreliable)

[Miklos Szeredi]

   Program received signal SIGBUS, Bus error.
   [Switching to Thread 16384 (LWP 7778)]
   0xf7ecf0c8 in fuse_mount_compat22 () from /usr/lib/libfuse.so.2
   (gdb) backtrace
   #0  0xf7ecf0c8 in fuse_mount_compat22 () from /usr/lib/libfuse.so.2
   #1  0xf7ecf34c in fuse_mount () from /usr/lib/libfuse.so.2
   #2  0xf7ecea00 in fuse_parse_cmdline () from /usr/lib/libfuse.so.2
   #3  0xf7eceb88 in fuse_setup_compat22 () from /usr/lib/libfuse.so.2
   #4  0x000191a0 in main (argc=3, argv=0xff8a3ae4) at sshfs.c:2514
   (gdb) 
 

OK, that implicates fuse, rather than sshfs.  The following patch
removes an unalinged access in that part of the code.  Can you please
try compiling fuse with this patch?

Thanks,
Miklos

Index: lib/mount.c
===
RCS file: /cvsroot/fuse/fuse/lib/mount.c,v
retrieving revision 1.33
diff -u -r1.33 mount.c
--- lib/mount.c 4 Dec 2006 12:45:19 -   1.33
+++ lib/mount.c 29 Dec 2006 13:59:47 -
@@ -153,6 +153,7 @@
 int rv;
 char ccmsg[CMSG_SPACE(sizeof(int))];
 struct cmsghdr *cmsg;
+int ret_fd;
 
 iov.iov_base = buf;
 iov.iov_len = 1;
@@ -182,7 +183,8 @@
 cmsg-cmsg_type);
 return -1;
 }
-return *(int*)CMSG_DATA(cmsg);
+memcpy(ret_fd, CMSG_DATA(cmsg), sizeof(ret_fd));
+return ret_fd;
 }
 
 void fuse_kern_unmount(const char *mountpoint, int fd)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#404904: Bug#404834: linux-image-2.6.18-3-sparc64: Kernel unaligned access kills at least sshfs (and may make USB unreliable)

[Miklos Szeredi]

 Also, sprach Miklos Szeredi am Freitag, den 29. Dezember 2006 um 15:11:
  OK, that implicates fuse, rather than sshfs.  The following patch
  removes an unalinged access in that part of the code.  Can you
  please try compiling fuse with this patch?
 
 I applied the patch to the fuse source (retrieved via apt-get source
 fuse, version is 2.5.3-4.1) like this:
 
   $ patch -p0  /home/smc/fuse.diff=20
   patching file lib/mount.c
   Hunk #1 succeeded at 133 with fuzz 2 (offset -20 lines).
   Hunk #2 succeeded at 163 with fuzz 1 (offset -20 lines).
 
 The applied patches look correct nevertheless.  I then built the
 package with
 
   $ dpkg-buildpackage -b -rfakeroot -us -uc
 
 and installed the debs for fuse-utils and libfuse2 (libfuse-dev was
 not installed and if I am not completely mistaken is irrelevant either
 way).
 
 I repeated the gdb steps but the same errors (bus access error,
 mountpoint unusable and has weird permissions) and kernel messages
 (see below), and the output looks conspicuously the same (n.b.: to be
 absolutely sure I restarted the machine first):
 
   $ gdb sshfs
   GNU gdb 6.4.90-debian
   Copyright (C) 2006 Free Software Foundation, Inc.
   GDB is free software, covered by the GNU General Public License, and you =
 are
   welcome to change it and/or distribute copies of it under certain conditi=
 ons.
   Type show copying to see the conditions.
   There is absolutely no warranty for GDB.  Type show warranty for detail=
 s.
   This GDB was configured as sparc-linux-gnu...Using host libthread_db li=
 brary /lib/v9/libthread_db.so.1.
  =20
   (gdb) set args [EMAIL PROTECTED]:/home/smc phobos/
   (gdb) run
   Starting program: /usr/bin/sshfs [EMAIL PROTECTED]:/home/smc phobos/
   [Thread debugging using libthread_db enabled]
   [New Thread 16384 (LWP 4600)]
  =20
   Program received signal SIGBUS, Bus error.
   [Switching to Thread 16384 (LWP 4600)]
   0xf7f9f0c8 in fuse_mount_compat22 () from /usr/lib/libfuse.so.2
   (gdb) backtrace
   #0  0xf7f9f0c8 in fuse_mount_compat22 () from /usr/lib/libfuse.so.2
   #1  0xf7f9f338 in fuse_mount () from /usr/lib/libfuse.so.2
   #2  0xf7f9ea00 in fuse_parse_cmdline () from /usr/lib/libfuse.so.2
   #3  0xf7f9eb88 in fuse_setup_compat22 () from /usr/lib/libfuse.so.2
   #4  0x000191a0 in main (argc=3D3, argv=3D0xff9b55d4) at sshfs.c:2514
   (gdb) The program is running.  Exit anyway? (y or n) y

I don't know what else could it be.  Can you compile fuse with
debugging enabled (DEB_BUILD_OPTS=nostrip,noopt) and repeat the
experiment?  The backtrace should then give a more detailed analysis.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#375521: sshfs: please fix

[Miklos Szeredi]

 Why won't fix ? I understand that the information is not available,
 but please don't return random values (7.5 T ?! what about 42 P ? or
 12456789 ?). The correct behaviour should be to return a more
 sensible value like 0 or some maximum value. Not something weird.

Already fixed in 1.7.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#402876: [fuse-devel] FUSE not working on ARM? Hangs during stat64

[Miklos Szeredi]

 On Thu, Dec 21, 2006 at 09:24:56AM +0100, Martin Michlmayr wrote:
  * Miklos Szeredi [EMAIL PROTECTED] [2006-12-20 19:37]:
We at Debian received the following bug report saying that FUSE is not
working on ARM.  I've verified this on two ARM platforms (IXP4xx and
IOP32x) and also checked that it's working fine on MIPS.  The problem
seems that it hangs in stat64.
   
   Can you please try the out-of-tree kernel module from the fuse-2.6.x
   package (use 'configure --enable-kernel-module).  That contains a
   workaround for a bug in the ARM architecture code.
   
   If this fixes the problem for you, then I would advise you to remind
   the ARM maintainer (Russel King) about this issue.
  
  The bug reporter confirms that it works with the modules from the
  fuse-2.6.1 package.  Russell, have you addressed this problem recently
  or is this still an open issue?  I've only tried 2.6.17 and 2.6.18 so
  far, nothing newer.  If there's a fix available, I can put it in
  Debian's 2.6.18 package that will ship with our next release.
 
 This is the first I've heard of a problem.
 
 What _exactly_ is the problem and can you provide a test case or
 instructions to reproduce it?

This is the dcache aliasing issue in get_user_pages() for anonymous
pages:

  http://lkml.org/lkml/2006/10/7/80

The reason why this only shows with FUSE is that ptrace() does it's
own redundant cache flushing, and other users of get_user_pages() like
SCSI and NFS direct-IO probably get less exposure on ARM than FUSE.

To reproduce, build a kernel with CONFIG_FUSE_FS, build the fuse
package (http://downloads.sourceforge.net/fuse/fuse-2.6.1.tar.gz) and
run one of the example filesystems.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#402876: [fuse-devel] FUSE not working on ARM? Hangs during stat64

[Miklos Szeredi]

 We at Debian received the following bug report saying that FUSE is not
 working on ARM.  I've verified this on two ARM platforms (IXP4xx and
 IOP32x) and also checked that it's working fine on MIPS.  The problem
 seems that it hangs in stat64.

Can you please try the out-of-tree kernel module from the fuse-2.6.x
package (use 'configure --enable-kernel-module).  That contains a
workaround for a bug in the ARM architecture code.

If this fixes the problem for you, then I would advise you to remind
the ARM maintainer (Russel King) about this issue.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#338496: sshfs: Additional Gnome application problems

[Miklos Szeredi]

 What I did was..
 
 1. Run normal gedit and save as doc.txt (which was empty file) in sshfs 
 mounted directory - success.
 2. Exit.
 
 and then:
 
 1. Run 'strace -o /tmp/gedit.strace gedit doc.txt'
 2. Try to save - failed.
 3. Exit - choose do not save.
 
 Hopefully I did what you expected.

Yes, thanks.  It looks like it is failing in rename().

I think the '-oworkaround=rename' option should solve your problem.

I'm considering turning on this option by default, because it looks
like quite a few applications depend on this behavior.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#395219: fuse-utils: configure from ntfs-g3 fails with ...

[Miklos Szeredi]

 
 i try to build the ntfs-g3 packge from
 http://mlf.linux.rulez.org/mlf/ezaz/ntfs-3g-20070920-BETA.tgz
 
 when i run ./configure i become this message:
 
 checking for fuse = 2.5.0... configure: error: ntfs-3g requires
 FUSE = 2.5.0. Please see http://fuse.sf.net/ or install __all__ the
 precompiled fuse packages.
 
 but my fuse utils hafe 2.5.3... does that package contains __all__
 utils from the fuse package?

All fuse packages:

fuse-utils
libfuse2
libfuse-dev

It's probably the last one you are missing.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#338496: sshfs: Additional Gnome application problems

[Miklos Szeredi]

   I am now having problems with GEdit saving files but this time it 
 says, that I have no rights to save a file. However, saving as in the 
 same location is possible but then saving normally with the new name 
 shows the same error (if you follow).
 
 I think this bug is related to lately closed this bug so I am reopening 
 it. If you think it is not then I will post new one.

I think this one is different.  The original bug report was about
statfs() returning zero free space.

Could you please do

  strace -o /tmp/strace gedit

and try to reproduce the bug with a minimal set of actions and exit
immediately?  And then attach the strace to the report or send it
privately.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#393693: fuse-utils: fusermount fails if the root FS is mounted read-only

[Miklos Szeredi]

 My /etc/mtab is a symlink to /proc/mounts. The point is that fusermount does
 not check if /etc/mtab is symlink and *unconditionally* tries to lock it and
 bails out if for some reason lock file can not be created.

Right.  It does check for a symlink (on umount), but only after having
done the lockfile thing.

 What about this patch (idea stolen from utils-linux' mount/fstab.c)?
 
 Index: fuse-2.5.3/util/fusermount.c
 ===
 --- fuse-2.5.3.orig/util/fusermount.c 2006-10-17 23:43:24.0 +0400
 +++ fuse-2.5.3/util/fusermount.c  2006-10-18 00:00:41.0 +0400
 @@ -104,6 +104,13 @@
  const char *mtab_lock = _PATH_MOUNTED .fuselock;
  int mtablock;
  int res;
 + struct stat mtab_stat;
 +
 + /* /etc/mtab could be a symlink to /proc/mounts */
 + if (!lstat(_PATH_MOUNTED, mtab_stat)) {
 + if (S_ISLNK(mtab_stat.st_mode))
 + return 0;
 + }
  
  mtablock = open(mtab_lock, O_RDWR | O_CREAT, 0600);
  if (mtablock = 0) {
 

Applied with minor modifications, thanks.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#393693: fuse-utils: fusermount fails if the root FS is mounted read-only

[Miklos Szeredi]

 Fusermount always fails if the root filesystem is mounted read-only, e.g.
 
 sshfs -C -o idmap=user -o -n just:/an /example
 fusermount: unable to open fuse lock file
 
 It would be nice if fusermount had a command-line switch to disable 
 updating of /etc/mtab (a la mount -n).

A much better solution (if you have a read only root) is to make
/etc/mtab be a symlink to /proc/mounts.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#393126: fuse-utils: some interaction with udev leaves us without a /dev/fuse device

[Miklos Szeredi]

 I have a bug similar to #368674.  Just booting up with an almost brand
 new udev installation, and sshfs fails with:
 fusermount: failed to open /dev/fuse: No such file or directory
 
 OK, so after a 'modprobe fuse', it works fine.

The problem is that automatic module loading doesn't work with udev.
The reason is that the device is only created _after_ the module is
loaded.

To get around this problem the next release of fuse (2.6.0) will
contain an init-script which will load the fuse module at boot time.

As a temporary measure you can also add a line containing 'fuse' to
/etc/modules.

Also see Ubuntu bug #1860.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#375521: sshfs: Displays incorrect free and total space

[Miklos Szeredi]

 I mount a remote file system with -o allow_other.
 
 The filesystem mounts successfully and I can access it.
 
 But, df -h reports 0% used and a total size of 7.5T. The actual total size is
 400GB, with around 97% used.

This is a FAQ:

  Why does df return strange values on partitions mounted via sshfs?
  
  Because the SFTP protocol doesn't have a statfs operation this is
  currently not possible to display proper usage on remote partition.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#368596: sshfs: Bus error on sparc64, leaves weird directory entries

[Miklos Szeredi]

 When I try to run sshfs on my Sun Enterprise 250 (2 x 400 MHz
 Ultrasparc II processors), I get a bus error:
 
  [EMAIL PROTECTED]:~/tmp$ mkdir mnt
  
  [EMAIL PROTECTED]:~/tmp$ ll
  total 64
  drwxr-xr-x   3 ron ron   126 May 17 11:42 ./
  drwxr-xr-x 190 ron ron 20480 May 23 07:20 ../
  drwxr-xr-x   3 ron ron25 May  3 14:21 mnt/
  
  [EMAIL PROTECTED]:~/tmp$ sshfs machine: mnt
  Bus error

Can you try running:

  sshfs -d -osshfs_debug ...

Also if you have gdb installed, it would be nice to see where it crashes:

  $ ulimit -c unlimited
  $ sshfs ...
  Bus error (core dumped)
  $ gdb sshfs core
  (gdb) bt

 If I try again I get:
 
  [EMAIL PROTECTED]:~/tmp$ sshfs machine: mnt
  fusermount: failed to access mountpoint /home/ron/tmp/mnt: Permission
  denied
 
and the mountpoint's directory entry is really strange:
 
  [EMAIL PROTECTED]:~/tmp$ ll
  total 64
  drwxr-xr-x   5 ron ron   144 May 23 07:28 ./
  drwxr-xr-x 190 ron ron 20480 May 23 07:20 ../
  ?-   ? ?   ?   ?? mnt

You can restore the original state with

   fusermount -u mnt

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#355827: sshfs: does not work

[Miklos Szeredi]

 ii  fuse-utils 2.2.1-4sarge2  Filesystem in USErspace (utilities)
 ii  libfuse2   2.2.1-4sarge2  Filesystem in USErspace library
 ii  sshfs  1.1-1  filesystem client based on SSH File Transfer

Try upgrading to FUSE-2.3 or later.  FUSE module from the official
kernel is not compatible with 2.2 or earlier FUSE releases.

Miklos



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#355827: sshfs: does not work

[Miklos Szeredi]

 [EMAIL PROTECTED]:~% ls -l /usr/bin/fusermount
 -rwsr-sr-x 1 root root 18376 2006-02-22 20:03 /usr/bin/fusermount
 [EMAIL PROTECTED]:~% ls -l `which fusermount`
 -rwsr-sr-x 1 root root 18376 2006-02-22 20:03 /usr/bin/fusermount
 [EMAIL PROTECTED]:~% sudo chmod a+s /usr/bin/fusermount
 [EMAIL PROTECTED]:~% ls -l /usr/bin/fusermount
 -rwsr-sr-x 1 root root 18376 2006-02-22 20:03 /usr/bin/fusermount
 [EMAIL PROTECTED]:~%
 
 Mmmm, that's weird.
 /me guesses he is missing something totally obvious.

OK, you don't need 'a+s' only 'u+s'.

Anyway if you still get the same error, there's something else going
on.  Perhaps some security module enabled in the kernel?

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#355827: sshfs: does not work

[Miklos Szeredi]

  The usual solution to this is
 
chmod u+s /usr/bin/fusermount
 
 I tried this and doesnt work.

What does the following show?

ls -l /usr/bin/fusermount

ls -l `which fusermount`

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#355827: sshfs: does not work

[Miklos Szeredi]

 Package: sshfs
 Version: 1.2-1
 Severity: grave
 Justification: renders package unusable
 
 After doing modprobe fuse, I try to do 
 
 sshfs [EMAIL PROTECTED]: dir/ 
 
 I give the passwd and then it says:
 
 fusermount: mount failed: Operation not permitted
 
 I don't know how to fix it.

The usual solution to this is 

  chmod u+s /usr/bin/fusermount

I don't know what the official stand on this, Fenio can you enlighten
us?

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#355827: sshfs: does not work

[Miklos Szeredi]

 strace -s1024 -f -o sshfs.log sshfs [EMAIL PROTECTED]: dir/
 
 and search the mount system call in sshfs.log. Do you find something like
 
 mount([EMAIL PROTECTED]:, dir/, fuse, MS_NOSUID|MS_NODEV,0x804d058) = 
 -1 EINVAL (Invalid argument) 
 
 Seems like fusermount and 2.6.15.6 (my kernel) don't want to talk to
 each other.

Hmm, I think this is different problem.  Can you also show the execve
fusermount ... line in the strace?  It looks as if it's some invalid
option, but strace doesn't show the mount options (the last argument).

Also, which package versions do you have?

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#352631: SONAME

[Miklos Szeredi]

 Seems you've changed ABI in 2.5.x version of FUSE, but you left old SONAME
 version, which causes many issues when filesystems that still want to work
 with such library.
 
 Please take a look at http://bugs.debian.org/352631
 
 Could you please update your SONAME version to reflect ABI changes?

It's a bug in the versioning of the fuse_mount() symbol.

The following patch should fix it.

Thanks for the report,
Miklos

Index: lib/mount.c
===
RCS file: /cvsroot/fuse/fuse/lib/mount.c,v
retrieving revision 1.24
diff -u -r1.24 mount.c
--- lib/mount.c 9 Jan 2006 11:33:04 -   1.24
+++ lib/mount.c 19 Feb 2006 17:56:48 -
@@ -291,4 +291,4 @@
 return fuse_mount_compat22(mountpoint, NULL);
 }
 
-__asm__(.symver fuse_mount_compat22,fuse_mount@);
+__asm__(.symver fuse_mount_compat22,[EMAIL PROTECTED]);


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#304562: FATAL: Error inserting fuse

[Miklos Szeredi]

  ip_tables: (C) 2000-2002 Netfilter core team
  fuse: Unknown symbol vfs_permission
  fuse: Unknown symbol vfs_permission
  fuse: Unknown symbol vfs_permission
 
 Since I'm not using 2.6 kernels I'm not quite sure what causes this
 problem. I'm CC'ing this message to Miklos (upstream author), maybe he will
 have some idea.
 
 In the meantime you can check whether new pre-version[1] fixes this bug. If
 yes I'll upload new package.
 
 Miklos I'd be very happy if you could comment it.

Which FUSE version?  Versions before 2.1 do not support kernels after
2.6.10.

Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#304562: FATAL: Error inserting fuse

[Miklos Szeredi]

 On Wed, Apr 20, 2005 at 10:46:13AM +0200, Miklos Szeredi wrote:
 Package: fuse-source
 Version: 2.2.1-4
 Severity: important
 
 So he's using latest stable release, this which security fix.

OK then the problem is either

 a) the FUSE kernel module is being built for the wrong kernel
version

 b) FUSE is not detecting the kernel version correctly

I suspect it's a), but who knows.

Please check configure output, especially kernel source directory
and kernel version.  If everything seems right, then please send the
output of configure and build.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#288081: who wants to package it?!

[Miklos Szeredi]

  I (lufs-cryptofs maintainer) support it! lufs-cryptofs is nice but needs
  to be audited and I do not like the code, especially because LUFS is
  dead upstream. encfs seems to be much better, and I want to get rid of
  CFS (that I currently use) RSN.
 
 PS: I see trouble coming. The package uses openssl but also the fuse
 library which is licensed under the GPL (without the OpenSSL remark). So
 the only way around this is:
 
  - replace openssl with gcrypt or such
  - add an exception to the GPL license of fuse (permission to link with
OpenSSL)

Permission granted :)

Do I need to put it in some magic licence file in future releases?

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#288081: who wants to package it?!

[Miklos Szeredi]

- replace openssl with gcrypt or such
- add an exception to the GPL license of fuse (permission to link with
  OpenSSL)
  
  Permission granted :)
  
  Do I need to put it in some magic licence file in future releases?
 
 That would be better. I am not the fuse maintainer (he is be'ing Cc'ed),
 but normaly I would request at least a GPG signed mail for license
 changes.

I just realized that the problem doesn't exist, since the fuse _library_
is under LGPL (since version 1.1).  The kernel module is obviously
GPL, but nobody links against that except the kernel.

Thanks,
Miklos


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]