dsisysteme
commented
1 month ago The issue is still present in 29.0.4
Open dsisysteme opened 2 months ago
dsisysteme
commented
1 month ago The issue is still present in 29.0.4
skjnldsv
commented
1 month ago Hi,
Can you share the exact 403 error from the logs please? I'm guessing your two instances share the same DB and data folder?
dsisysteme
commented
1 month ago Hi,
Could you specify the information you are missing regarding the apache2 logs we included in the issue description?
Regarding the second question, indeed, the two instances share the same database and the same data folder. We also have a Redis instance that stores PHP sessions and distributed cache.
skjnldsv
commented
1 month ago I meant the content of the 403 response. Either the json entry in nextcloud.log if any, or the browser network request response.
skjnldsv
commented
1 month ago On a slight different note, can you share how you configured/enabled your shared session ?
dsisysteme
commented
1 month ago Unfortunately, there is no log in the nextcloud.log.
Here is an image of the sequence of requests:
All PUT requests with a 201 status are handled by node 2, and the 403 errors are on node 1. It seems that the node which handled the MKCOL request is the one where the PUT requests have a 201 status.
here is the extract of the responses from the requests at the browser level: PUT 403:
HTTP/1.1 403 Forbidden
Date: Mon, 29 Jul 2024 13:37:03 GMT
Server: Apache
Strict-Transport-Security: max-age=15768000
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: noindex, nofollow
X-XSS-Protection: 1; mode=block
Content-Security-Policy: default-src 'none';
Content-Type: application/xml; charset=utf-8
Keep-Alive: timeout=5, max=92
Connection: Keep-Alive
Transfer-Encoding: chunkedPUT 201:
HTTP/1.1 201 Created
Date: Mon, 29 Jul 2024 13:37:03 GMT
Server: Apache
Strict-Transport-Security: max-age=15768000
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: noindex, nofollow
X-XSS-Protection: 1; mode=block
Content-Security-Policy: default-src 'none';
X-OC-MTime: accepted
OC-FileId: 250391672oc7elpk9mous
X-Request-Id: rz2VVlqVxSm4UqXra3xI
OC-ETag: "c1677a26a6ae01fc281bb0a4905400a3"
X-Debug-Token: rz2VVlqVxSm4UqXra3xI
ETag: "c1677a26a6ae01fc281bb0a4905400a3"
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Keep-Alive: timeout=5, max=100
Connection: Keep-AliveFor PHP sessions, we use the following configuration at the fpm pool level on the 2 nodes:
php_admin_value[session.save_path] = tcp://<redis-server>:6379
php_admin_value[session.save_handler] = redisFor nextcloud, we force the distributed cache to index 1 to avoid conflicts.
"dbindex": 1
skjnldsv
commented
1 month ago here is the extract of the responses from the requests at the browser level: PUT 403:
Please also give us the xml body response, not only the headers
dsisysteme
commented
1 month ago Sorry for the misunderstanding.
Here is the XML body of the 403 response:
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\Forbidden</s:exception>
<s:message/>
</d:error>
The issue is still present in 29.0.5
⚠️ This issue respects the following points: ⚠️
Bug description
We have noticed that in a load-balanced environment without Sticky Sessions, dragging and dropping a folder containing multiple files no longer works. In the case of an environment with 2 application servers, only half of the files are uploaded correctly. The web interface displays error messages saying "Operation blocked by access control."
We can see that one of the nodes is returning 403 errors on file uploads while the second one handles them correctly. Based on repeated tests, it's clear that this issue is not specific to any particular node. When we isolate either node 1 or node 2, drag and drop functionality works.
For your information, this works perfectly in 27.1.4 under the same conditions.
Steps to reproduce
Expected behavior
The folder and all files should be uploaded without any error messages.
Installation method
Community Manual installation with Archive
Nextcloud Server version
29
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.3
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Fresh Nextcloud Server install
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
Browser log (Firefox 127.0):
Apache2 first node:
Apache2 second node: