I also got the issue on Debian 9 Stretch and could solve it on the same way, thanks guys!
On 6.2.3 in comparison i’m now experiencing slow seahub performance for generating thumbs and loading the folder contents. Syncing via the Client runs smooth on all OS anyway in testing env as well as productive environment.
I’m going to test of disabling memcached changes that and update you.
After testing, the memcache error only occur after Seahub started for a few seconds. Later the error disappear. It is mostly likely a problem that memcache is not properly initialized after Seahub started. Apart from this, there are no other observable problems.
So I think this error is not an issue.
MemcachedCache is not thread-safe when Seahub is configured to use multi-thread mode. So we use PyLibMCCache.
I’m confused, the fix was to add threads = 5 according to @lian but did I understand you correct that we should not add that to the config?
Can I ask why PostgreSQL is not supported in 6.2.3?
server-session.c(271): Unknown database type: pgsql
6.2.2 was ok with PostgreSQL
Hi,
I’m also having problems with Seafile 6.2.3 not working with pgsql. 6.2.2 works fine.
Maybe it was accidentally compiled without pgsql support?
Now the situation is:
If you add threads=5 to runtime/seahub.conf, the CPU usage will be high with WSGI mode. The discussion is here.
If you remove threads=5 from runtime/seahub.conf, the CPU usage will be normal, but some memcached related error msgs appears, that what we are discussing here in this post. I think this maybe a issue of the django-pylibmc module, so I posted an issue on the django-pylibmc Github project, but there is no response yet.
Something more, we plan to move the gunicorn config file, which is runtime/seahub.conf, out from runtime folder to conf folder on 6.3.0, so user can configure it manually just like seafile.conf, seahub_settings.py, etc.
I have a workaround for the missing PostgreSQL support: I switched from Seafile to Resilio Sync. Works great. Fast, low on resources, and does not need a database.
This is proprietary SW, closed source and mainly PAID solution, thanks not. And how you know there’s no need database? I’m sure that they are using something like SQLite packed in. You can use default installation of Seafile where is used SQLlite which works greate for years. Don’t mess up peoples mind with your bullsh*t.
Yeah, that isn’t the solution that works for me. I just want to use Seafile with Postgres as I’m using it now on 6.2.2.
Just keep 6.2.2, thay may forgot link some libraries or what. And it better for you install newer version later, some release bugs will be reparied.
Of course, I’m just reporting a bug, not rushing anywhere. 
Anyone knows what Oauth2 grant types support Seafile ?
Great job to bring this feaure on board Thanks in advance!
We ues the authorization code OAuth grant type.
Thanks Lian,
Does this Oauth implementation also supports refresh_token grant type ?
https://bshaffer.github.io/oauth2-server-php-docs/grant-types/refresh-token/
Because I notice after testing that I’m getting a new pair of access Tokens and refresh tokens on every click on Single-Sign-On. Theoretically if as a user I already Authorized an app, I should get a refresh token that lasts some days/weeks depending on the oauth server config, and in a new request by the same user just use this refresh token to get a new access ( And thus avoid getting the authorize thing everytime )
To clarify, right now the flow is something like this:
https://seafile/accounts/login/ SSo link:
GET https://mysso/app_dev.php/de/oauth/authorize?response_type=code
we click on authorize, is POST to the same url, which generates an authorization code and we are redirected to the redirect_uri:
https://seafile/oauth/callback/?code=aded49b3a6b7906ef992349cf163b651bed7d5f7
It will be possible in case we detect is a user that already authorized, hence he has a refresh token, to reply directly with the refresh token ?
Or seafile expects that we land with the code parameter ? If we could also send the refresh_token instead of a code, then it could get a new token directly using this one, and thus making a standard Oauth2 implementation.
So we reply with:
https://seafile/oauth/callback/?refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
and internally seafile just get’s the access token with this instead of the authorization code:
$ curl https://mysso/de/oauth/token TestClient:TestSecret -d 'grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
Then we will get also an access_token, but without generating a new refresh_token:
{“access_token”:“471360a64b80c03e67ac8d8906e368e14fe03e3d”,“expires_in”:3600,“token_type”:“Bearer”,“scope”:“user”}
Is there any plans to support this ?
在6.3.3社区版中依然发现了memcache的如上报错问题，按照您说的配置，修改后测试发现可以，但是原理不是很明白！