Bug 216230 - devel/tevent: upgrade from 0.9.28 -> 0.9.31 causes gvfs-mount fail for smb shares, affects also x11-fm/thunar, x11-fm/pcmanfm, x11-fm/nautilus, x11-fm/caja
Summary: devel/tevent: upgrade from 0.9.28 -> 0.9.31 causes gvfs-mount fail for smb sh...
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-ports-bugs (Nobody)
Depends on:
Reported: 2017-01-18 11:59 UTC by Matthias Petermann
Modified: 2017-04-02 09:45 UTC (History)
7 users (show)

See Also:

gvfs-mount ktrace (11.85 KB, application/empty)
2017-01-18 11:59 UTC, Matthias Petermann
no flags Details
gvfsd ktrace (156 bytes, application/empty)
2017-01-18 12:00 UTC, Matthias Petermann
no flags Details
gvfsd-smb ktrace (3.76 KB, application/empty)
2017-01-18 12:00 UTC, Matthias Petermann
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Petermann 2017-01-18 11:59:33 UTC
Created attachment 179028 [details]
gvfs-mount ktrace


To me this problem was initially indirectly noticeable. I am using a custom pkg repository which provides pkgs close to head in a rolling manner. Some day, x11-fm/thunar and x11-fm/pcmanfm were no longer able to access smb shares after a pkg update.


I did reproduce the issue in an isolated environment (a VM with
only FreeBSD base + dbus and gvfs pkgs installed) and was 
able to reproduce the issue on the command line.

	# kldload fuse
	# chmod a+rw /dev/fuse
	# service dbus onestart
With tevent 0.9.28:

	% dbus-launch csh
	% gvfs-mount smb://WORKGROUP\;mpeterma@proliant/public
	% gvfs-mount -l	
	Mount(0): public on proliant -> smb://WORKGROUP;mpeterma@proliant/public/
	  Type: GDaemonMount
	(Ok, expected good behavior)
With tevent 0.9.31:

	% dbus-launch csh
	% gvfs-mount smb://WORKGROUP\;mpeterma@proliant/public
	(waiting forever..., unexpected bad behavior)

Further Details

 - I am attaching ktrace captures of gvfs-mount, gvfsd and gvfsd-smb
   of the test run with tevent 0.9.31 (with which the issue occurs)
 - Around the same time the gvfs issue occured, also the net/samba36
   port smbd daemon wasn't able to startup (and still is). I fixed this
   permanently by upgrading to samba44, but samba36 users will very 
   likely report similiar issues.
 - downgrading exclusively tevent to 0.9.28 on my production desktop
   solved the Thunar / PCManFM issue.
 - Other users do have the same issue reported in FreeBSD Forums:
 - The SVN commit which introduced tevent 0.9.31 was r430417 and the
   comment stated: 
    "Update Samba4* supplimentary libraries to the newer versions."
Known Workaround

 - locally downgrade to tevent 0.9.28, this can be enforced by 
   downloading the 0.9.28 pkg and installing it via
	# pkg add -f tevent-0.9.28.txz
Comment 1 Matthias Petermann 2017-01-18 12:00:07 UTC
Created attachment 179029 [details]
gvfsd ktrace
Comment 2 Matthias Petermann 2017-01-18 12:00:30 UTC
Created attachment 179030 [details]
gvfsd-smb ktrace
Comment 3 Gleb Popov freebsd_committer 2017-02-14 06:06:52 UTC
Possibly related: https://mail.kde.org/pipermail/kde-freebsd/2017-January/024882.html
Comment 4 Matthias Petermann 2017-02-14 18:41:06 UTC
Hello, thanks for the reference to the kde-freebsd mailing list. I contacted Dwayne (the author of the post) and he was kind to verify that downgrading to tevent 0.9.28 solved the problem for him, too. So we need to assume that with this issue, all major file managers seem to be impacted.
Comment 5 Dwayne MacKinnon 2017-02-22 21:22:03 UTC
See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215859
Comment 6 Matthias Petermann 2017-04-02 09:45:17 UTC

with the recent changes in head, as well in 2017Q2 (tested today) this problem seems to be gone and it works now also with the tevent version 0.9.31.

I could not track this down to a single package, but the most significant I have seen was that samba36 is deprecated now and substituted on the fly by samba43, which might be the reason that this is now working (as the commit which initially causes the issue did update some port versions to support samba 4).

If there speaks nothing against, I'd recommend to close this bug.

Best regards & thanks for getting this problem solved,