⚠️ This issue respects the following points: ⚠️
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?
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.
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_sharescould be set toyes. 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_sharescan be set tono, 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
./occ config:app:set files_sharing hide_disabled_user_shares --value noExpected 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_shareswhich defaults toyes. 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?
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.