Closed arturondc37 closed 1 year ago
Hi, please update to 24.0.9 or better 25.0.3 and report back if it fixes the issue. Thank you!
My goal is to add a label like e.g. 25-feedback to this ticket of an up-to-date major Nextcloud version where the bug could be reproduced. However this is not going to work without your help. So thanks for all your effort!
If you don't manage to reproduce the issue in time and the issue gets closed but you can reproduce the issue afterwards, feel free to create a new bug report with up-to-date information by following this link: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C0.+Needs+triage&template=BUG_REPORT.yml&title=%5BBug%5D%3A+
@szaimen I upgraded my nextcloud installation to 25.0.3 and the issue persist. Also as a side effect document versioning is not working, in fact, from the previous version it didn't work but I thought the problem was something with the installation but in this version it doesn't work either. In block storage everything works perfectly. Maybe is a Linode issue with Object Storage Backend. I'm going to try using an Amazon object storage.
@szaimen Problem Solved, It seems the problem is related to the Object storage URL in Linode S3. When a bucket is created in Linode the bucket address is, for example: mybucket.region.linodeobjects.com But the above causes, in the case of Nextcloud, that it creates a folder inside the bucket with the name of the bucket. To avoid this problem, region.linodeobjects.com should be used as the URL because the bucket name is specified in a separate variable. Finally the correct syntax would be like this: Example for environment in docker: -OBJECTSTORE_S3_HOST=us-southeast-1.linodeobjects.com -OBJECTSTORE_S3_BUCKET=mybucket -OBJECTSTORE_S3_KEY=mykey -OBJECTSTORE_S3_SECRET=mysecret -OBJECTSTORE_S3_PORT=443 -OBJECTSTORE_S3_SSL=true -OBJECTSTORE_S3_REGION=us-southeast-1 -OBJECTSTORE_S3_USEPATH_STYLE=true
But hey, the above apparently is not a problem of the Linode object storage but of the way in which Nextcloud manages those configurations.
So this issue can be marked as solved
So is this a docker variable problem?
@szaimen No, it's not a docker variable problem. It is the way in which each provider presents its url to access the bucket. In the specific case of Linode, when you create a bucket, the URL represents the direct access to the content inside the bucket and not the root directory. Making an analogy is as if I created a folder in /home/ called example, the path to the folder would be /home/example but the path I really need is /home/ because in that root directory I will be able to see the example folder. So it's not a problem, it's just knowing these details because each provider has its way of managing its object storage.
All right, so I think this should potentially be documented here? https://docs.nextcloud.com Moving to the correct repo then.
Your issue was two-fold:
The docs technically covered this before, but were a bit confusing. That's been remedied some recently, but I can see already see there's room for further improvement. Namely to make sure it is clear that the hostname
(aka: OBJECTSTORE_S3_HOST
for Docker) is meant to be the S3 endpoint, not the direct bucket URL.
https://www.linode.com/docs/products/storage/object-storage/guides/urls/#cluster-url-s3-endpoint
As for use_path_style
(aka: OBJECTSTORE_S3_USEPATH_STYLE
):
You may need to use use_path_style if your non-Amazon S3 store does not support requests like https://bucket.hostname.domain/. Setting use_path_style to true configures the S3 client to make requests like https://hostname.domain/bucket instead.
Often both styles will work with some providers. The main issue is that the hostname
must only ever be the S3 endpoint.
Documenting all of this clearly is also challenging because a few other configuration combinations will technically sometimes work, but they won't get the results you might expect or may be fragile (i.e. break in the future).
It gets confusing very quickly!
I tried to narrow down the choices recently in the latest docs to the two reliable combinations that always (to my knowledge) work and always place your data where you're expecting (regardless of provider/object store platform)
From the looks of it, Linode would work either as:
hostname: us-southeast-1.linodeobjects.com
bucket: mybucket
use_path_style: true
With the above resulting in your data being stored in https://us-southeast-1.linodeobjects.com/mybucket/
or:
hostname: us-southeast-1.linodeobjects.com
bucket: mybucket
use_path_style: false
With the above resulting in your data being stored in https://mybucket.us-southeast-1.linodeobjects.com/
I'll see about:
hostname
parameter in the NC Admin Manual. And possibly even language to make it clear we don't want the direct bucket URL, if one is provided.
⚠️ This issue respects the following points: ⚠️
Bug description
After installation I uploaded a file and I can't copy it to another folder. But I can do the following operations without errors:
Steps to reproduce
Expected behavior
Being able to copy files from one folder to another without problems.
Installation method
Official Docker image
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.0
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
Nextcloud Logs
Additional info
No response