[Bug]: Meaning and default of hide_disabled_user_shares was changed and functionality lost

⚠️ This issue respects the following points: ⚠️

This is a bug, not a question or a configuration/webserver/proxy issue.
This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
I agree to follow Nextcloud's Code of Conduct.

Bug description

Prior to nextcloud 34.0.2, shared files of disabled users were blocked for external access (links etc.), but would still be allowed to be accessed by internal users. So if a person left the organization, all shares sent to third parties stopped working, but colleagues could still access internal folders. In case internal access wasn't wanted, hide_disabled_user_shares could be set to yes. So the two options were Internal access only and no access to files shared by disabled users.

In #62092 this behavior was changed: Now all access is blocked by default (internal and external). In order to grant access to these files, hide_disabled_user_shares can be set to no, but this also enables external access (e.g., via link). So now the two options are no access and internal_and_exeternal_access. There is no option to replicate the previous default. Also, documentation wasn't adapted.

In practice this means that after upgrading nextcloud many users see files/folders disappear and the only way to quickly restore their access is to also allow access for external users via links.

Steps to reproduce

Install Nextcloud 34.0.1
Share a file internally and externally
Disable the account sharing the file
Check the shared file still visible internally
Check the shared file not accessible externally
Upgrade to Nextcloud 34.0.2
See the shared file not visible internally anymore
Change config: ./occ config:app:set files_sharing hide_disabled_user_shares --value no
Check the shared file visible internally again
Check the external link accessible

Expected behavior

Restore the previous meaning and default of hide_disabled_user_shares, so things won't break on upgrade.

Introduce a new configuration setting hide_disabled_user_external_shares which defaults to yes. This accomplishes the goal of #62092 without breaking access on upgrade and maintain the ability to keep internal shares working while blocking external shares (which was and IMHO is a reasonable default in terms of balancing security and functionality). Adapt documentation.

Nextcloud Server version

34

Operating system

Other

PHP engine version

PHP 8.3

Web server

Nginx

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Updated from a MINOR version (ex. 32.0.1 to 32.0.2)

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

Default user-backend (database)
LDAP/ Active Directory
SSO - SAML
Other

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

This affects multiple versions of Nextcloud, as it was backported to 34, 33, 32, 31 and 30.

[stable34] fix(files_sharing): Allow access to shares by disabled users if hide_disabled_user_shares is enabled #62150
[stable33] fix(files_sharing): Allow access to shares by disabled users if hide_disabled_user_shares is enabled #62151
[stable32] fix(files_sharing): Allow access to shares by disabled users if hide_disabled_user_shares is enabled #62152
[stable31] fix(files_sharing): Allow access to shares by disabled users if hide_disabled_user_shares is enabled #62153
[stable30] fix(files_sharing): Allow access to shares by disabled users if hide_disabled_user_shares is enabled #62154

This was done as a security measurement for the default case.

So for now this is expected behavior and the documentation likely needs to be adapted:
https://github.com/nextcloud/documentation/blob/4379a3274443c7567437c1164349f408ecc796e4/admin_manual/configuration_user/user_configuration.rst?plain=1#L213

Your request would be to split the toggle into?

hide disabled user external shares
hide disabled user internal shares

@susnux

Your request would be to split the toggle into?

hide disabled user external shares

hide disabled user internal shares

@susnux My request would be to either return to the previous behavior or to split it into two toggles, as suggested by you, correct.

Please priorize this.

We cannot set hide_disabled_user_shares = no, because it would allow former employees to exfiltrate data when getting terminated and/or it would make it harder to stop compromised accounts from exfiltrating data.

But we also need the ability for other employees to grab shared data from employees that left recently (before their grace period expires and their accounts are fully deleted).

I was under the impression setting it to "no" would only allow shares from disabled users to be accessed. From the previousl comment it sounds like shares "former employees" (already deleted) would also be reachable again? Please clarify. If only "disabled but still in the system" would be allowed then that's the expected behaviour, isn't it?

I was under the impression setting it to "no" would only allow shares from disabled users to be accessed. From the previousl comment it sounds like shares "former employees" (already deleted) would also be reachable again? Please clarify. If only "disabled but still in the system" would be allowed then that's the expected behaviour, isn't it?

Deleting an Accounts deletes their share-entries from the database. There is no way to bring back shares of deleted accounts (without restoring these data from backups).

hide_disabled_user_shares Changed its meaning, see OP.

That is bad for us, as we depend on the remaining colleagues of disabled Accounts (=people who left TU Wien, but are still in a grace-period before their disabled accounts get deleted (including all files and shares)) being able to pull shared files to re-host them, but we need disabled account's public shares to be gone immediately and its currently impossible to satisfy both requirements anymore.

Splitting this setting into 2 would solve the issue. -> Please prioritize this change, as we need it urgently.

Any updates on this? :)

No, otherwise someone would have posted something here. Please try to avoid such comments, that don't add anything to the discussion or help closing the issue.

I interpret your reply as "there wont be a fast solution to this" as opposed to no news, which is hard to interpret and difficult to work with internally when people keep asking for updates on their "lost files".

So while being sorry, for creating noise for you, your reply made it possible for me to start working on a workaround for us.
I/we would prefer a proper solution to this, but since important people are starting to get nervous, this is my life now, I guess.

To add something of technical substance, the idea we are testing is to add something like this to our maint-cronjob running every 15 min:

        WITH to_deactivate as (
            SELECT distinct userid FROM oc_preferences WHERE NOT (appid='files' AND configkey='quota' AND configvalue='1 B') AND
            userid IN (SELECT owncloud_name FROM oc_ldap_user_mapping LEFT JOIN oc_preferences ON (owncloud_name=userid AND appid='user_ldap' AND configkey='foundDeleted') WHERE configvalue IS NOT NULL)
        )
        UPDATE oc_share SET share_type=share_type+1000 WHERE share_type>2 AND share_type<1000 AND (uid_owner IN (select userid from to_deactivate) OR uid_initiator IN (select userid from to_deactivate))

(a quota of 1 byte is a marker for "disabled account, grace period running, deletion pending" on our system)

as in: set share types of "external" share types to something invalid when an account is disabled and set hide_disabled_user_shares=no.
When somebody comes back, one just needs to undo the share_type+1000 (part of the same cronjob).
At least it seems to work as expected in our testing environment and to my understanding nothing more is needed.

Navigation Menu

Repository navigation

[Bug]: Meaning and default of `hide_disabled_user_shares` was changed and functionality lost #63159

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

Is this bug present after an update or on a fresh install?

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Meaning and default of hide_disabled_user_shares was changed and functionality lost #63159

Description

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

Is this bug present after an update or on a fresh install?

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

Activity

grembo commented on Aug 11, 2026

susnux commented on Aug 19, 2026

grembo commented on Sep 7, 2026

someone-somenet-org commented on Sep 21, 2026

neufeind commented on Sep 21, 2026

someone-somenet-org commented on Sep 21, 2026

someone-somenet-org commented on Oct 1, 2026

provokateurin commented on Oct 5, 2026

someone-somenet-org commented on Oct 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[Bug]: Meaning and default of `hide_disabled_user_shares` was changed and functionality lost #63159