fusesmb/smbnetfs SIGABORT in getattr() because libsmbclient is not thread safe

Thank you for your bug report. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. I have classified this bug as a bug in fusesmb.

I can reproduce this bug under two conditions.

1) If my network is not set up correctly, and it is impossible to connect to a MS networking server even with smbclient, then any attempt to use fusesmb (understandably) fails in exactly the way that Dr_Willis reports

2) If my network is set up correctly, and I CAN connect to MS networking servers as verified using smbclient, then my very first attempt to use fusesmb for a user always fails exactly as Dr_Willis has described, with the additional detail that ~/.smb/fusesmb.cache does not get created, but ~/.smb/fusesmb.cache.pid does get created. After approximately 5 minutes have passed, ~/.smb/fusesmb.cache.pid suddenly disappears and ~/.smb/fusesmb.cache suddenly appears. All subsequent attempts to use fusesmb work perfectly after that point, and the only way I can reproduce Dr_Willis's symptoms again is by manually deleting ~/.smb/fusesmb.cache

It's a known problem. See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497572

meaning It's the new UNSTABLE version of fusesmb that is in Debian lenny repositories.
It is inherited through Ubuntu repo.

I expirienced same problem in Thunar as the person above.

SOLUTION:
Untill fusesmb is fixed use "smbnetfs" instead. Works perfectly.

A Thought: why Debian and Ubuntu used unstable version of fusesmb?

Seems this solution is still buggy. The connection is working much longer but still fails eventually with same symptoms.

Ubuntu should go to same version of fusesmb as in 8.04 untill fusesmb team fixes the bug.

Is there anybody out there who has the same problem with smbnetfs? I have, both fusesmb and smbnetfs both tend to crash in the same way. smbnetfs leaves no notice in it's logfile.

Florian: I haven't tried smbnetfs on Ubuntu, but in parallel to testing 8.10 I was experiment with Arch Linux and decided to use smbnetfs. I ran into a very similar bug. Could this be what you are finding? Versions are probably similar.

http://bugs.archlinux.org/task/12032

I have the same problem with smbnetfs. It holds the network longer than fusesmb but fails eventually.
I thought the problem is mostly in Thunar, but using the smb network through CLI gives the same failure result.
It seems that the libsmbclient version in ubuntu 8.10 is the problem. 8.04 probably has a more stable version.

For comparison, the same shares mounted on the same machine with "mount -t cifs" work perfectly and seem 100% stable.

What is the relationship between this bug and https://bugs.launchpad.net/ubuntu/+source/samba/+bug/290673 ?

John Carlyle-Clarke: Yes, it sound similar to the archlinux bug. I saw crashes in talloc_abort_double_free, but in fusesmb, not in smbnetfs. In the meanwhile I really doubt that it is the applciation (smbnetfs, fusesmb) but more the library libsmbclient.

I tried for both (smbnetfs and fusesmb) the older version used in Hardy, but the problem persists. I did not (yet) however tried to go back in the version of libsmbclient.

FWIW, I downloaded and installed fusesmb_0.8.7-1_amd64.deb and libsmbclient_3.0.28a-1ubuntu4.4_amd64.deb from Hardy and that seems to eliminate the "Transport endpoint is not connected" errors I was getting previously with 'fusesmb' mounted shares.

I can confirm that downgrading manually to libsmbclient_3.0.28a-1ubuntu4 only fixes the described problem. It breaks the gfvs-backends package though but it doesn't seem to have any negative effect so far other than an annoying icon in the notification area and warnings from package installation tools. This confirms that the problem is in libsmbclient_3.2.3-1ubuntu3 shipped with intrepid.

Hmm, there is a more serious side effect after the reboot though: the computer:/// protocol stops working in nautilus (and some other problems like missing label names from local hard disk volume mounts) -- all due to a broken gvfs-backends apparently.

I noticed these problems with gvfs / nautilus as well. I wound up switching my window manager to fluxbox and removing gvfs-backends and nautilus*. Probably not the most elegant solution, but I need fusesmb more than gnome, etc.

Actually you can downgrade libsmbclient manually to prevent from braking package dependencies. Just download a correct package from here http://packages.ubuntu.com/hardy-updates/libsmbclient and unpack it to <somedir>. Then do:

  sudo mv /usr/lib/libsmbclient.so.0 /usr/lib/libsmbclient.so.0.bak
  sudo cp <somedir>/CONTENTS/usr/lib/libsmbclient.so.*
  ldconfig

I've been running the system downgraded this way for a couple of days now on two PCs while actively using fusesmb'd resources from Nautilus and other Gnome programs and no problems so far.

Errr, sudo ldconfig of course.

And cp <somedir>/CONTENTS/usr/lib/libsmbclient.so.* /usr/lib/ :)

Sorry, but it's really sad that there is no preview/edit function for comments...

I can confirm that on Xubuntu 8.10, the workaround posted by Dmik works for me. The SMB connection is stable while browsing the network with Thunar.

Not actually related to the defect but I've just bumped into it. Intensive multithreaded access to the same files on a share (in my case, make command run in parallel mode using four threads) causes problems (sporadic errors like 'no such file or directory' or 'file read error' that disappear after a re-run of the command) with the downgraded version of libsmbclient too. However, fusesmb suffers much more from that problem than smbnetfs. If I limit the number of threads to just one (make -j 1) the problems disappears completely (both in fusesmb and in smbnetfs).

Some more offtopic, JFYI: setting smb_open_files_max to 500 instead of 100 in .smb/smbnetfs.conf helped with smbnetfs and multithreaded access, no errors any more. The complex build process is a really good stress test for a FS.

Thanks for the threading tip. I've just edited my startup file to disable multi-threaded operation, with a command line like this:

  smbnetfs /my/mountpoint -s

So far, it hasn't crashed using this mode. (I suspect I have lost some performance, though.)

Update: smbnetfs crashed again even when running with -s.

Bug 293233 contains a SIGABRT backtrace which might be the same crash we're seeing here.

Tying together more related bug reports...

(Debian 503038 and Samba 5847 contain some enlightening comments from the smbnetfs and samba developers)

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503038
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497572
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502129

Ehm... Any chance this gets fixed any time soon? It's really starting to piss me and all of my co-workers off... :(

Before each update we now have to run 'install -f' and afterwards re-install the old libsmbclient package, since we don't want to override the files in the base filesystem...

From comments appear to be confirmed

New >Confirmed

Quoting bigal50 (<email address hidden>):
> >From comments appear to be confirmed

Probably the same than Debian #497572, duplicated in #502129 which was
reported as upstream #5847:
https://bugzilla.samba.org/show_bug.cgi?id=5847

As mentioned in upstream #5847, software affected by such problem
should work around it.

It's quite probable that, at some moment in Debian samba bug triage, I
reassign #502129 to fusesmb.

please update SMBNetFS package to latest git version. It does not contain the bug described here due to libsmbclient isolation in separate process.

smbnetfs has the same problem, and the developer already has a fix in testing.

http://sourceforge.net/tracker/?func=detail&atid=857137&aid=2492545&group_id=171223

Hi,

I was wondering if this is still a problem and if you could test this on lucid.

Thanks
chuck

Smbnetfs has been fine for me since I upgraded to karmic. But I'm not sure if I still have any fixes in place. As far as I'm aware it's all stock.

same problems in lucid-current

adding -s parameter is a workaround for problem in lucid

On Wed, 10 Mar 2010 21:09:58 -0000
Robert Garshaw <email address hidden> wrote:

> Smbnetfs has been fine for me since I upgraded to karmic. But I'm not
> sure if I still have any fixes in place. As far as I'm aware it's all
> stock.

This problem was fixed in smbnetfs-0.5.x.
Use smbnetfs-0.5.2 or latest git

Mikhail Kshevetskiy

> --
> fusesmb/smbnetfs SIGABORT in getattr() because libsmbclient is not thread safe
> https://bugs.launchpad.net/bugs/198351
> You received this bug notification because you are subscribed to
> smbnetfs in ubuntu.
>
> Status in Samba: Invalid
> Status in “fusesmb” package in Ubuntu: Confirmed
> Status in “samba” package in Ubuntu: Confirmed
> Status in “smbnetfs” package in Ubuntu: Confirmed
> Status in Debian GNU/Linux: New
>
> Bug description:
> Installed and enabled fusesmb Just like i have done in the past , following
> the FuseSmb wiki page. However no shares or workgroups are shown now under
> hardy. As the root user, a 'ls -l' of the Mounted fusesmb point gives the odd
> output of.
>
> ls -l
>
> drwxr-xr-x 2 willis willis 4096 2008-02-16 07:30 Music
> d????????? ? ? ? ? ? Network
>
> as a user ls -l gives .
>
> drwxr-xr-x 2 willis willis 4096 2008-02-16 07:30 Music
> drwxr-xr-x 3 willis willis 4096 2008-03-04 08:10 Network
>
>
> the fusesmb -d option (for debugging) is not really giving any info as to
> what is failing.
>
> Aparently related to
> https://bugs.launchpad.net/ubuntu/+source/fusesmb/+bug/157494
>
> fusesmb Installed: 0.8.7-1
>
>

Marking smbnetfs fixed in Lucid per comments 32 and 35

Marking the samba part as wontfix since libsmbclient is not threadsafe by design and upstream doesn't consider it a bug.

Anyone knows is fusesmb is still affected ?

2010/3/18 Thierry Carrez <email address hidden>:
> Anyone knows is fusesmb is still affected ?

Sure. The are only two way to avoid this problem:
  * single thread application
  * make libsmbclient threadsafe.

SMBNetFS-0.5.x uses several single thread child processes to
communicate with samba (and isolate buggy libsmbclient code from the
rest of smbnetfs). It was done to get better performance and
stability.

Mikhail Kshevetskiy

> --
> fusesmb/smbnetfs SIGABORT in getattr() because libsmbclient is not thread safe
> https://bugs.launchpad.net/bugs/198351
> You received this bug notification because you are subscribed to
> smbnetfs in ubuntu.
>
> Status in Samba: Invalid
> Status in “fusesmb” package in Ubuntu: Confirmed
> Status in “samba” package in Ubuntu: Won't Fix
> Status in “smbnetfs” package in Ubuntu: Fix Released
> Status in Debian GNU/Linux: New
>
> Bug description:
> Installed and enabled fusesmb  Just like i have done in the past , following the FuseSmb wiki page.  However no shares or workgroups are shown now under hardy.
> As the root user, a 'ls -l' of the Mounted fusesmb point gives the odd output of.
>
> ls -l
>
> drwxr-xr-x 2 willis willis      4096 2008-02-16 07:30 Music
> d????????? ? ?      ?              ?                ? Network
>
> as a user ls -l gives .
>
> drwxr-xr-x 2 willis willis      4096 2008-02-16 07:30 Music
> drwxr-xr-x 3 willis willis      4096 2008-03-04 08:10 Network
>
>
> the fusesmb -d option (for debugging) is not really giving any info as to what is failing.
>
> Aparently related to  https://bugs.launchpad.net/ubuntu/+source/fusesmb/+bug/157494
>
> fusesmb   Installed: 0.8.7-1
>
>
>

Actually Samba upstream does consider the non-threadsafeness of libsmbclient as a bug, it's just that it's going to take a while to fix it :-).

We're slowly but surely moving towards getting a thread safe libsmbclient, Can't promise when it will be done, but it is our intent to get there.

So at the moment, libsmbclient is not thread safe. So using separate processes in SMBNetFS is the *only* way to safely use libsmbclient, so I'd argue that libsmbclient in this case isn't exactly "buggy", but just not working in the way you want :-).

When we finally announce libsmbclient is thread-safe, and your threaded code using it breaks, *then* you can call it buggy :-). But not before please - unless you have specific single-threaded bugs you know about and need fixing. But if that is the case please report them to bugzilla.samba.org and we'll fix them !

Jeremy.

For what it is worth I have been using smbnetfs on hardy jaunty and now lucid without problems. When I started out, on hardy fusesmb was not working, which is why I used smbnetfs. I have just revisited and tried fusesmb again. It does not work on Lucid and I am seeing this.
Running in debug mode I get repeatedly told fusesmb.cache is already running

in .smb there is a fusesmb.cache.pid file that refers to a non-existent process
there is no fusesmb.cache file
so for example on a fully up to date Kubuntu Lucid machine I get this after trying to mount my samba shares with fusesmb (smbnetfs is not yet installed on this machine)

administrator@administrator-laptop:~/.smb$ ls
fusesmb.cache.pid fusesmb.conf
administrator@administrator-laptop:~/.smb$ cat fusesmb.cache.pid
2721
administrator@administrator-laptop:~/.smb$ ps -e | grep fuse
 2801 pts/0 00:00:00 fusesmb
administrator@administrator-laptop:~/.smb$

smbnetfs continues to work fine so I will not change what I am doing with that