1) yes, it seems, that session was valid.
So, the Owncloud client does not authorize each reuqest, but uses
sessions? Any information about expiration?
2) Gluster mountpoint was mountted as /data/clouddatafolder/username
We stopped the glusterfs volume, so the mountpoint was broken on the
webserver (transport endpoint is not connected)
3) I wonder, what will happen, if we will umount /data/clouddatafolder,
which is Owncloud's main data folder, on the active server?
All of the owncloud clients, will start to delete data from local computers?
Can u explain this case a bit in detail?
4) Simpler case: what will happen with data on the client's side, if we
will move the user's home directory with data, on the working server, to
/tmp?
Janis Viklis
<mailto:[email protected]>
On 03.09.2015. 12:29, Klaas Freitag wrote:
On 02.09.2015 15:35, Janis Viklis | Failiem.lv wrote:
Hi.
Can someone explain, why owncloud client (1.8.4) is "able to sync",
inspite of changed password?
The case:
1) we changed the user's password
2) unmounted username's data folder from the webserver
3) owncloud client, deleted all files from the client, inspite of that
user's password was changed
How can that happen - "syncing" with old credentials?
Why the hell it deleted the files?
It seems that the session maintained between client and server was
still valid for a bit of time. That is tricky, I agree.
How did you mount the user data folder? Actually the server does
detect umounts of external storages and returns 503 to the client
which handles this gracefully, meaning does not delete.
This seems not to have worked in this case, and you should follow up
on that and create a bug report in core.
Thanks, and sorry for the trouble.
klaas
_______________________________________________
User mailing list
[email protected]
http://mailman.owncloud.org/mailman/listinfo/user
_______________________________________________
User mailing list
[email protected]
http://mailman.owncloud.org/mailman/listinfo/user
