server
server copied to clipboard
[Bug]: No Permissions on nested folders when using S3 storage.
⚠️ This issue respects the following points: ⚠️
- [X] This is a bug, not a question or a configuration/webserver/proxy issue.
- [X] This issue is not already reported on Github (I've searched it).
- [X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
- [X] Nextcloud Server is running on 64bit capable CPU, PHP and OS.
- [X] I agree to follow Nextcloud's Code of Conduct.
Bug description
I recently added the External Storage app to my nextcloud instance. I was able to connect to a bucket in my S3 storage however although I can create new folders and files in Nextcloud, I can only access at the root level only. If I attempt to go further than root I get the following:
"You don't have permission to upload or create files here."
Other external devices and WebDav locations are fine. I am able to create nested folders and files directly in the S3 browser without any issues.
Steps to reproduce
- Add Extra Storage App
- Connect your S3
- Create a folder within S3 root folder on NC
Expected behavior
Add and remove file in nested folders
Installation method
Community Manual installation with Archive
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
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?
- [X] Default user-backend (database)
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other
Configuration report
No response
List of activated Apps
Extra Storage and other default apps
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
No response
Which nc version?
Which nc version?
Version 25.0.1
what kind of S3 storage ? (Minio, AWS, etc)
am not aware of any regressions there and our CI tests S3 with Minio
what kind of S3 storage ? (Minio, AWS, etc)
am not aware of any regressions there and our CI tests S3 with Minio
I tried AWS and idrive E2
My steps with Minio (S3 compatiable) and Nextcloud 25.0.1:
- Run
docker run -p 9000:9000 minio/minio server /data
- Login into the minio web UI (credentials are minioadmin/minioadmin)
- Enable external storage
- Go to the external storage panel
- Add an S3 external storage of type "Amazon S3" to a mount point "/s3"
- As bucket name type "mybucket"
- Hostname "localhost", Port 9000
- Authenticate with access key: minioadmin/minioadmin
- Tick "Use path style"
- Click save and see green check
- Go to the files app
- Create a folder "/s3/test"
- Upload some files into "/s3/test"
- Create a folder "/s3/test/nested"
- Upload some files into "/s3/test/nested"
- Navigate back and forth through the folders => works fine
- Check the Minio console, this is what I see:

- Reset Nextcloud, keeping the bucket with the data
- Reconfigure the external storage as before
- Enter "/s3/test/nested"
- See the files are there
So there is no regression.
Please check how you configured the nested folders in S3 directly to make sure Nextcloud has access there with the given access credentials.
you can also try to occ files:scan --all
it is possible that if you originally didn't set permissions right in S3 and fixed them, maybe Nextcloud didn't detect this, so rescanning might fix that
I do not use selfhosted S3 solution. I use AWS and IDRIVE E2. It's a bug with NC and nothing to do with S3. Thank you anyway
My steps with Minio (S3 compatiable) and Nextcloud 25.0.1:
- Run
docker run -p 9000:9000 minio/minio server /data
- Login into the minio web UI (credentials are minioadmin/minioadmin)
- Enable external storage
- Go to the external storage panel
- Add an S3 external storage of type "Amazon S3" to a mount point "/s3"
- As bucket name type "mybucket"
- Hostname "localhost", Port 9000
- Authenticate with access key: minioadmin/minioadmin
- Tick "Use path style"
- Click save and see green check
- Go to the files app
- Create a folder "/s3/test"
- Upload some files into "/s3/test"
- Create a folder "/s3/test/nested"
- Upload some files into "/s3/test/nested"
- Navigate back and forth through the folders => works fine
- Check the Minio console, this is what I see:
![]()
- Reset Nextcloud, keeping the bucket with the data
- Reconfigure the external storage as before
- Enter "/s3/test/nested"
- See the files are there
![]()
So there is no regression.
Please check how you configured the nested folders in S3 directly to make sure Nextcloud has access there with the given access credentials.
I do not use selfhosted S3 solution. I use AWS and IDRIVE E2. It's a bug with NC and nothing to do with S3. Thank you anyway
I would appreciate it if someone from Next Cloud team to take a look at this and fix the issue because without actual S3 support this app is useless. It's not only me with this issue, others also posted on NC forum and reddit. You can also try IDRIVE E2 or AWS both free to reproduce the issue. Thank you
Could it be that there is a problem with the idrive e2 implementation? I have also been struggling with idrive e2, but I was able to use minio without any trouble. I have noticed that the permissions in the oc_filecache table are strange when using e2. I have not been able to track down the cause for this yet. I am happy to share some access keys to test buckets on e2 if somebody wants to have a closer look.
thanks for confirming that more people are having this issue
@juliushaertl @icewind1991 can you confirm ?
would be good to see also if it's a regression in Nextcloud 25 or if the issue exists in earlier versions also
I have had this issue at already in NC 23. I had hoped upgrades would resolve this. I also eeplicated it on a completely fresh docker Nextcloud instance.
is it going to get fixed in the next version 25.0.2?
It seems nothing get fixed on NC. I am in process of moving to OC. 90% of apps do not work with NC 25. You can close this if you want. Thanks for the effort tho.
@shawnlocal Sorry to hear you ran into difficulty. I wish I'd seen your report earlier. NC works fine with genuine AWS S3 as either Primary Storage or External Storage across all of my test instances. And numerous people are using it. Typically the issues that arise are with third-party (non-AWS) implementations which aren't fully S3 compatible (we use the AWS S3 SDK) or they use different parameter names so people mix up which ones go where.
We've recently extensively rewritten the S3 related docs for External Storage to try to help a bit with this:
https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/external_storage/amazons3.html
It seems like it's too late in your case, but just in case it's not, I'd be interested in:
- the actual Nextcloud log entries around the time period you got/get the
You do not have permission to upload or create files here
message (which isn't even an S3 error message; it's from Files so that's weird) - the output of
occ files_external:list -a --output=json_pretty
(Redact anything you deem sensitive and feel free to exclude any non-S3 mount entries if desired)
Create a folder within S3 root folder on NC
@shawnlocal - I just reread and saw the above. Are you saying you mounted this S3 bucket as your root folder in NC?
If so, that could be relevant. We need the full config since your reproduction step just says "Connect your S3". :-)
P.S. If you want to use S3 Object Store as your Primary Storage, there's a dedicated means for using Object Storage as Primary Storage:
https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/primary_storage.html
Another common scenario that might cause this is entering a hostname (when using AWS) containing the bucket name.
Unfortunately your report and reproduction steps didn't include much detail about your actual configuration.
@NSOLONAR: Please provide your config details if you're having the same symptom as the original report. Specifically, the exact configuration you used on the Docker setup and/or the output of occ files_external:list -a --output=json_pretty
or equivalent.
Closing since the follow-up information needed has not been provided after nearly a year.