Win 7 - 6.0.6 conflict with "Base Filtering Engine"


#1

Hi

I’m migrating my user data to a new Seafile server and have installed the latest Seafile client on a Windows 7 64-bit machine after completely removing all previous Seafile installations and data folders.

I’m using the latest Windows server with nginx and https support.

As soon as I selected to sync a folder with the server the Seafile client became extremely sluggish and unusable. A click takes minutes to register.

The client is uploading data to the server, but is it expected for the client to be completely unusable while this happens?

Is there anything I can do. I need to roll this out to my users, but can’t with this state.
It didn’t seem to be a problem with the old server, so I wonder if there’s something I can do, or an error somewhere?

The logs look okay to me - but I’m not sure what I’m looking for:

[05/09/17 13:18:09] http-tx-mgr.c(3400): Upload with HTTP sync protocol version 1.
[05/09/17 13:18:09] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'init') --> ('normal', 'check')
[05/09/17 13:18:09] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'check') --> ('normal', 'commit')
[05/09/17 13:18:09] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'commit') --> ('normal', 'fs')
[05/09/17 13:18:09] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'fs') --> ('normal', 'data')
[05/09/17 13:18:19] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'data') --> ('normal', 'update-branch')
[05/09/17 13:18:28] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'update-branch') --> ('finished', 'finished')
[05/09/17 13:18:28] sync-mgr.c(702): Repo 'Hardware' sync state transition from 'uploading' to 'initializing'.
[05/09/17 13:18:49] sync-mgr.c(1516): Removing blocks for repo Hardware(078a2de1).
[05/09/17 13:19:04] sync-mgr.c(702): Repo 'Hardware' sync state transition from 'initializing' to 'committing'.
[05/09/17 13:19:07] repo-mgr.c(2592): Adding remaining files for .
[05/09/17 13:19:37] sync-mgr.c(702): Repo 'Hardware' sync state transition from 'committing' to 'uploading'.
[05/09/17 13:19:37] http-tx-mgr.c(3400): Upload with HTTP sync protocol version 1.
[05/09/17 13:19:37] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'init') --> ('normal', 'check')
[05/09/17 13:19:37] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'check') --> ('normal', 'commit')
[05/09/17 13:19:37] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'commit') --> ('normal', 'fs')
[05/09/17 13:19:38] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'fs') --> ('normal', 'data')
[05/09/17 13:19:47] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'data') --> ('normal', 'update-branch')
[05/09/17 13:19:52] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'update-branch') --> ('finished', 'finished')
[05/09/17 13:19:52] sync-mgr.c(702): Repo 'Hardware' sync state transition from 'uploading' to 'initializing'.
[05/09/17 13:20:07] sync-mgr.c(1516): Removing blocks for repo Hardware(078a2de1).
[05/09/17 13:20:31] sync-mgr.c(702): Repo 'Hardware' sync state transition from 'initializing' to 'committing'.
[05/09/17 13:20:31] repo-mgr.c(2592): Adding remaining files for .
[05/09/17 13:21:04] sync-mgr.c(702): Repo 'Hardware' sync state transition from 'committing' to 'uploading'.
[05/09/17 13:21:04] http-tx-mgr.c(3400): Upload with HTTP sync protocol version 1.
[05/09/17 13:21:04] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'init') --> ('normal', 'check')
[05/09/17 13:21:04] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'check') --> ('normal', 'commit')
[05/09/17 13:21:04] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'commit') --> ('normal', 'fs')
[05/09/17 13:21:05] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'fs') --> ('normal', 'data')
[05/09/17 13:21:15] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'data') --> ('normal', 'update-branch')
[05/09/17 13:21:34] http-tx-mgr.c(1109): Transfer repo '078a2de1': ('normal', 'update-branch') --> ('finished', 'finished')
[05/09/17 13:21:37] sync-mgr.c(702): Repo 'Hardware' sync state transition from 'uploading' to 'initializing'.
[05/09/17 13:22:07] sync-mgr.c(1516): Removing blocks for repo Hardware(078a2de1).
[05/09/17 13:22:46] sync-mgr.c(702): Repo 'Hardware' sync state transition from 'initializing' to 'committing'.
[05/09/17 13:22:50] repo-mgr.c(2592): Adding remaining files for .

Thanks for any help.


#2

I’ve narrowed the problem down to McAfee. If we uninstall McAfee the client works fine. If we run McAfee the client is unusable.

We run McAfee VirusScan Enterprise 8.8.

Does anyone have any suggestions how to work around this conflict? Obviously we can’t uninstall McAfee as a solution.


#3

Your computer would be more secure afterwards.

Another solution would be to contact McAfee to let them fix their software. It’s obviously a bug.


#4

It’s our corporate standard, I don’t think I’m going to get very far there.

Is there any logs I can create or way I can debug this further? It doesn’t completely stop it working, just makes it crazily slow.


#5

Hi, you can configure your VSE installation to exclude dirs, files or even processes.

You can stop the accessprotection or onaccess scanner via vse console.

Disable step by step if the access scanner is disabled and it works, configure excludes for your seafile installation and vice versa with accessprotection

The vse logs are stored in %deflogdir%


#6

Then fix it.


Why do everyone claim that Nextcloud is better then seafile?
#7

Yep, that’s what I’m here trying to do.

The logs don’t say that it’s blocking anything, in fact even with the scanners disabled the problem still occurs.
The application freezes for around a minute, then you have perhaps 10 seconds where it’s completely usable - then freezes again.

The sync works perfectly, I assume because that’s a background process.


#8

Okay, after some digging I’m not sure it is McAfee after all.

There is a service, “Base Filtering Engine”. Stopping that Windows service makes Seafile respond normally.
Starting that service brings the seafile-applet to its knees.

Does that make any sense?

The BFE “is a service that manages firewall and IPsec policies and implements user mode filtering”.


#9

Here’s a video of what I mean: https://youtu.be/vpdYxeNW2y4

I don’t think there’s a problem with the server side as the client can be made to work perfectly, but to be sure I disabled SSL and ran the service on port 8000, and also set up a completely separate Seafile Server on Linux instead of Windows – the client was still unusably slow whatever I did at the server end.

Stopping the Base Filtering Engine service fixes the problem completely – the client works perfectly, but that’s not a solution that I can suggest to the users.

Stopping that service also stops “IPsec Policy Agent”, “Windows Firewall” and “IKE and AuthIP IPsec Keying Modules” services, but I don’t believe any of those services are causing the issue as stopping them individually while leaving the Base Filtering Engine running does not fix the problem.

There’s nothing obvious in the Seafile logs, the Event viewer, the Windows Firewall logs or the McAfee logs.

Is there anything anyone can suggest?