[Question] ACL behavior: Cannot grant access to specific subfolder without parent folder permissions

ℹ️ Support
, , , , ,
1
Support intro

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 32.0.2 (Nextcloud Hub 25 Autumn)
  • Operating system and version (e.g., Ubuntu 24.04):
    • Linux 6.1.0-40-amd64 x86_64
  • Web server and version (e.g, Apache 2.4.25):
    • Apache/2.4.65 (Debian)
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • replace me
  • PHP version (e.g, 8.3):
    • 8.3.28
  • Is this the first time you’ve seen this error? (Yes / No):
    • No
  • When did this problem seem to first start?
    • replace me
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • Manual
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • No

Summary of the issue you are facing:

I’m evaluating Nextcloud Team folders for replacing a Windows shared drive system. I need to understand if the current ACL behavior is by design.

Use case: “I want to give access to ONE specific subfolder to ONE user, without them having access to anything else.”

With the current implementation, a user with explicit +read permission on a deep subfolder (Folder_B/SB_B) cannot access it if they don’t have permissions on parent folders.

Steps to replicate it (hint: details matter!):

  1. Create team folder “ToutBIS” with base permissions for group “ToutBIS”

  2. Enable Advanced Permissions

  3. Create folder structure: Folder_B/SB_B

  4. Set ACL: Remove ALL permissions for group “ToutBIS” on root folder /

  5. Set ACL: Grant +read permission ONLY for specific user on Folder_B/SB_B

  6. Login as that user and try to access Folder_B/SB_B

Expected result: User can access Folder_B/SB_B based on explicit ACL permission Actual result: User cannot access the subfolder

Current ACL Configuration:

./occ groupfolders:permissions 19
+---------------+---------------------+-----------------------------------------+
| Path          | User/Group          | Permissions                             |
+---------------+---------------------+-----------------------------------------+
| /             | group: ToutBIS      | -read, -write, -create, -delete, -share |
| Folder_B/SB_B | user: Utilisateur 1 | +read                                   |
+---------------+---------------------+-----------------------------------------+
```

Log entries

No relevant log entries

Web Browser

No

Web server / Reverse Proxy

The output of your Apache/nginx/system log in /var/log/____:

PASTE HERE

Configuration

Nextcloud

The output of occ config:list system or similar is best, but, if not possible, the contents of your config.php file from /path/to/nextcloud is fine (make sure to remove any identifiable information!):

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***.test.bis-sorbonne.fr",
            "localhost",
            "***REMOVED SENSITIVE VALUE***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "32.0.2.2",
        "overwrite.cli.url": "https:\/\/cloud.test.bis-sorbonne.fr\/",
        "overwriteprotocol": "https",
        "proxy": "http:\/\/proxy-pmf.univ-paris1.fr:3128",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "knowledgebaseenabled": false,
        "skeletondirectory": "",
        "default_language": "fr",
        "force_language": "fr",
        "default_locale": "fr_FR",
        "default_phone_region": "FR",
        "force_locale": "fr_FR",
        "defaultapp": "files",
        "maintenance": false,
        "mail_smtpmode": "smtp",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_sendmailmode": "smtp",
        "mail_smtpport": "25",
        "theme": "",
        "loglevel": 0,
        "log_type": "file",
        "logfile": "data\/nextcloud.log",
        "app_install_overwrite": [
            "circlesdb",
            "sharingpath",
            "deck"
        ],
        "updater.release.channel": "stable"
    }
}

Apps

Enabled:

  • activity: 5.0.0-dev.0
  • admin_audit: 1.22.0
  • announcementcenter: 7.2.2
  • app_api: 32.0.0
  • auto_groups: 1.6.2
  • bruteforcesettings: 5.0.0-dev.0
  • calendar: 6.1.0
  • circles: 32.0.0
  • cloud_federation_api: 1.16.0
  • collectives: 3.3.0
  • comments: 1.22.0
  • contacts: 8.1.0
  • contactsinteraction: 1.13.1
  • dashboard: 7.12.0
  • dav: 1.34.2
  • deck: 1.16.2
  • external: 7.0.0
  • federatedfilesharing: 1.22.0
  • files: 2.4.0
  • files_downloadlimit: 5.0.0-dev.0
  • files_pdfviewer: 5.0.0-dev.0
  • files_reminders: 1.5.0
  • files_sharing: 1.24.1
  • files_trashbin: 1.22.0
  • files_versions: 1.25.0
  • groupfolders: 20.1.4
  • logreader: 5.0.0-dev.0
  • lookup_server_connector: 1.20.0
  • notes: 4.12.4
  • notifications: 5.0.0-dev.0
  • oauth2: 1.20.0
  • onlyoffice: 9.11.0
  • password_policy: 4.0.0-dev.0
  • privacy: 4.0.0-dev.0
  • profile: 1.1.0
  • provisioning_api: 1.22.0
  • recommendations: 5.0.0-dev.0
  • related_resources: 3.0.0-dev.0
  • serverinfo: 4.0.0-dev.0
  • settings: 1.15.1
  • sharebymail: 1.22.0
  • spreed: 22.0.4
  • systemtags: 1.22.0
  • tables: 1.0.1
  • text: 6.0.1
  • theming: 2.7.0
  • twofactor_backupcodes: 1.21.0
  • updatenotification: 1.22.0
  • user_saml: 7.1.0
  • user_status: 1.12.0
  • viewer: 5.0.0-dev.0
  • webhook_listeners: 1.3.0
  • workflowengine: 2.14.0
    Disabled:
  • encryption: 2.20.0 (installed 2.10.0)
  • federation: 1.22.0 (installed 1.12.0)
  • files_accesscontrol: 2.0.3 (installed 2.0.3)
  • files_external: 1.24.0 (installed 1.22.0)
  • files_rightclick: 0.15.1 (installed 1.6.0)
  • firstrunwizard: 5.0.0-dev.0 (installed 2.11.0)
  • nextcloud_announcements: 4.0.0-dev.0 (installed 1.11.0)
  • photos: 5.0.0-dev.1 (installed 2.3.0)
  • sharingpath: 0.4.4 (installed 0.4.4)
  • support: 4.0.0-dev.0 (installed 1.5.0)
  • survey_client: 4.0.0-dev.0 (installed 1.10.0)
  • suspicious_login: 10.0.0-dev.0
  • twofactor_nextcloud_notification: 6.0.0-dev.0
  • twofactor_totp: 14.0.0
  • user_ldap: 1.23.0 (installed 1.17.0)
  • weather_status: 1.12.0 (installed 1.7.0)
  • whiteboard: 1.4.2 (installed 1.4.2)

Question for Developers

Is this a limitation that could be addressed, or is the current parent-folder-traversal requirement a fundamental architectural choice that won’t change?

This would help us make an informed decision between Nextcloud and SharePoint for our institutional migration.

Thank you for your time and for the excellent work on Nextcloud and the groupfolders app.

Any guidance on this behavior would be greatly appreciated.

2

I don’t use group folders, so maybe that is why I don’t see this, but I’m able to share a sub folder to a user without sharing the to level folder.

3

IMO this is exactly the expected result. This is the case in all filesystems I’m aware of and IMHO there is no (good) way to access subfolder without root folder access.. where do you expect to see this folder? in the root? what should happen if you have

/root
/root/a
/root/a/x <- allow access
/root/b
/root/b/x <- allow access

do you expect to see x two times? should the view merge them? how to differentiate? so access to parent folder is natural prerequisite to access subfolders.

4

Exactly, for a user to have access to a folder they need to be able to navigate to that folder. This is in my opinion pretty normal and expected behaviour for an ACL system.

This is absolutely possible with the groupfolders ACL system.

Example:

Folder structure:

  • Groupfolder (“/”)
    • Folder “/A”
      • Folder “/A/1”
      • Folder “/A/2”
    • Folder “/B”

Groups:

  • “Everyone” (every user on instance is in this group, no need to create this manually see here)

Users:

  • “User X” (the user to get access to the subfolder and nothing else)

Desired permissions configuration:

  • “User X” has access to Folder “/A/1” and nothing else

Groupfolder Settings:

acl-inherit-per-user mode disabled (this is the default and very important for the ACLs below to work)

ACLs:

  • Groupfolder (“/”)
    • “User X”: read only
  • Folder “/A”
    • “everyone”: deny all
    • “User X”: read only
  • Folder “/A/1”
    • “everyone”: deny all
    • “User X”: full permissions
  • Folder “/A/2”
    • “everyone”: deny all
  • Folder “/B”
    • “everyone”: deny all

Obviously in this example nobody has access to “/B”, in reality you need a lot more rules as other users/groups need their access too.

I call this “everyone”: deny all rule “default deny”. It stops rights from the parent folder from inheriting.

Caveats/Pitfalls

1:

“User X” will have access to files directly within “/” or “/A” (so for example “/test.png” or “/A/test.md”) (unless you add default deny rules to those files as well, which is a terrible idea, because those files - unlike your folder structure - might change frequently).

Solution: Organize all your files into folders above a certain “depth”, so use the first folder levels to configure the permissions only (and have nobody (or at least not regular user) with write access) and once you have fine-grained-enough permissions at a certain depth put files into there (or further subfolders).

2:

If you add a Folder “/A/3” DO NOT FORGET TO ADD THE DEFAULT DENY RULE or “User X” will have read access.

Solution: In my opinion this footgun needs to be automated away for a large-scale setup or it is just a matter of time until someone forgetting this causes a data leak.

This is one of the many reasons why developed (for a client of my employer with a huge instance with thousands of groupfolders) an open-source nextcloud app called Organization Folders, which provides an abstraction across groupfolder ACLs and provides a simpler (and in my opinion more intuitive) interface to configure permissions (which then get transformed into (as more users/groups get permissions rather-verbose) ACLs in the background, utilizing the exact default-deny-rule schema I described above).
This footgun does not exist in organization folders, as you need to explicitly opt-into inheritance from the parent folder.

I don’t know your exact use-case of course, but “institutional” implies to me a large-scale setup with rather complex permissions, which is exactly what Organization Folders was made for, so maybe check it out :slight_smile:

If you have any more questions about ACLs don’t hesitate to ask.

2 Likes
5

Thank you so much for this great detailed and helpful response!

Configuration findings:

The acl-inherit-per-user parameter didn’t exist in my configuration, so I believe it defaults to false. To be sure, I explicitly set it.

Testing your proposed architecture:

I installed group_everyone (which I wasn’t familiar with - thank you for this information!) and started testing.

Issue encountered with this approach:
When trying to apply “everyone”: deny all on Folder “/A”, I hit a limitation:
“Error: You cannot remove your own read authorization”

Since the manager user is part of “everyone”, they cannot deny themselves access.

Adapted configuration:
I modified the setup to use:

  • Groupfolder groups: “ToutBIS” (everyone except manager) with Read/Share/Write + Manager user separately with Read/Share/Write
  • ACL management: Manager user

Test results:
Your “default deny” strategy works perfectly!

“User X” can access /A, /A/1, and /A/2 as expected. When I remove +read on /A for “User X”, they can no longer traverse - this confirms the expected behavior.

Question about file organization:
Could you elaborate on this part of your solution?

“Organize all your files into folders above a certain ‘depth’, so use the first folder levels to configure the permissions only […] and once you have fine-grained-enough permissions at a certain depth put files into there”

If I understand correctly:

  • Levels 0-2: Structure/permissions only - no files stored at these levels
  • Level 3+: Actual files and working directories

Organization Folders:

You’ve identified our context perfectly :slight_smile: - “institutional” does indeed imply large-scale setup with complex permissions, which is exactly our situation. We’re migrating from a Windows shared drive system with thousands of users and extremely complex ACLs.

I’m very curious to test Organization Folders.

I’ll need to plan a downgrade to NC31 first, which I can’t do immediately, but this is definitely a high priority on our evaluation roadmap.

Thank you again for your rich and practical response!

1 Like
6

Thank you @muzicman0 for your response. You’re right - my question is specifically about groupfolders ACLs rather than the standard Nextcloud sharing system.

7

Thank you @wwe for raising these UI/UX considerations! You make valid points about potential folder display confusion.

In our case, folder naming would be carefully controlled, but I appreciate you thinking through these practical implications. My focus was specifically on groupfolders ACLs technical feasibility.

Thank you for your response!

8

Exactly. The exact cut off point can be anything, if you want to go crazy with permissions differentiation it could also be “levels 0-5” and “levels 6+”, but its unlikely this is needed.

I personally prefer it with one additional rule: the folders of level 3+ (or whatever you choose) don’t have any ACLs set, so they simply inherit the permissions from the parent folder. This is not strictly neccessary, but in my opinion it keeps complexity down when thinking about permissions, because you don’t have to think about the whole path when understanding the permissions of a certain file.

You can choose the cut-off point of the levels for any sub-tree of your folder structure individually. For example you could allow files directly in /B but not directly in “/A” only “/A/1/” and “/A/2”.

In Organization Folders we call the lower levels “folder resources” (or “managed folders”) (created and managed in the org folder permissions UI) and “regular folders” (or “unmanaged folders”) (normal folders created within managed folders or unmanaged folders in the files app).

Sorry, should have checked in the UI if my example can be replicated as-is. I pretty much never use the UI to set ACLs, I only ever write code, that writes ACLs, so I completely forgot about that.

In case you are talking about config.php: It is an app config, not an instance config, so it can be read with occ config:app:get groupfolders acl-inherit-per-user --default-value=false and set with occ config:app:set groupfolders acl-inherit-per-user --value false (saved in the database, not in the config file).

I don’t think it is possible to downgrade a nextcloud instance, so you would have to restore from an NC 31 backup (if the instance was ever on 31) or create a new instance with 31.

We plan on adding support for NC 32 in January (February at the latest).
Since it is meant for enterprise-usecase instances (that are usually not on the latest version anyways, AFAIK with NC enterprise you can even still get security-patches for NC 21) support for the newest version is not our highest priority, but we need support for at least one still-supported-without-nextcloud-enterprise version ourselves, so that is the goal.

9

Thank you so much @TessyPowder for these additional clarifications!

Your clarification about levels 3+ having no ACLs (simple inheritance) is very helpful - this indeed keeps complexity down and makes permissions more predictable.

Your detailed responses give me exactly what I need to test and present this approach to our working group. I’ve requested that our production instance (NC 31) be replicated to our testing environment so we can properly evaluate Organization Folders very soon.

I’ll definitely share our experience feedback once we’ve had a chance to test Organization Folders in our context at the Sorbonne Inter-university Library.

Thanks again for taking the time to provide such a practical guidance!

1 Like
10

Thank you. Please also reach out if you have any problems during testing, I would love to help as questions inform what I need to add to the projects documentation (which I am working on expanding and moving from the README to a proper docs page).

1 Like