Problem identifying when a sharing user has removed themselves

OK. I’ve recently converted our company’s app from Dropbox to OwnCloud. It features a sharing dialog which allows the user to add or remove users to a shared folder, and it quietly updates files in that folder with data tailored for all the users. Of course, not every user can see everyone who the folder is shared with, so it relies on the folder owner to make sure the list is complete.

It’s all working fine until a non-owner user removes themselves from the folder. They can’t actually delete the share through the API, so instead our code has them decline it – fair enough. But then we hit the problem: the “files_sharing/api/v1/shares” endpoint, if you provide a “path” argument and “shared_with_me” is false or absent, while “reshares” is true… leaves out the field from the XML response. (I only see the field if “path” is blank and “shared_with_me” is true.) This means there is no way of telling whether the share has been declined or not, so no way of telling which users in the returned set should actually be removed from it.

Am I missing something? Is there a straightforward way to get a list of the users who actually have access to a folder – as opposed to including users who have actually cancelled their access, but may possibly change their mind someday?

This is ownCloud Server 10.14, and the Windows client version is 5.3.2.15463.

Steps to reproduce

Expected behaviour

Tell us what should happen

Actual behaviour

Tell us what happens instead

Server configuration

Operating system:

Web server:

Database:

PHP version:

ownCloud version: (see ownCloud admin page)

Updated from an older ownCloud or fresh install:

Where did you install ownCloud from:

Signing status (ownCloud 9.0 and above):

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

The content of config/config.php:

Log in to the web-UI with an administrator account and click on
'admin' -> 'Generate Config Report' -> 'Download ownCloud config report'
This report includes the config.php settings, the list of activated apps
and other details in a well sanitized form.

or 

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your ownCloud installation folder

*ATTENTION:* Do not post your config.php file in public as is. Please use one of the above
methods whenever possible. Both, the generated reports from the web-ui and from occ config:list
consistently remove sensitive data. You still may want to review the report before sending.
If done manually then it is critical for your own privacy to dilligently
remove *all* host names, passwords, usernames, salts and other credentials before posting.
You should assume that attackers find such information and will use them against your systems.

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder.

Are you using external storage, if yes which one: local/smb/sftp/…

Are you using encryption: yes/no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/…

LDAP configuration (delete this part if not used)

With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your ownCloud installation folder

Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap';


Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.

Client configuration

Browser:

Operating system:

Logs

Web server error log

Insert your webserver log here

ownCloud log (data/owncloud.log)

Insert your ownCloud log here

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log 
c) ...

I did some research on this. Perplexity Ai had this suggestion. It may get you in the right direction.

When a non-owner user declines a share in ownCloud Server 10.14, the current OCS Share API behavior makes it challenging to programmatically identify declined shares. Here’s the structured analysis and potential solutions:

Key Issue with API Response

  • The /files_sharing/api/v1/shares endpoint doesn’t explicitly indicate declined shares when using path + reshares=true parameters[5]. Declined shares remain in the response without a clear status flag, requiring alternative methods to detect them.

Workaround Solutions

  1. Check Share State Attribute
    Use the state field in the share API response:

    ... 
    

    Filter shares where state=2 to identify declined shares[1][4].

  2. Alternative Endpoint Parameters
    Query with shared_with_me=true to list all shares visible to the current user, including declined ones:

    GET /ocs/v1.php/apps/files_sharing/api/v1/shares?shared_with_me=true&reshares=true
    

    This may reveal declined shares that are hidden in other parameter combinations[5].

  3. Manual Tracking
    Maintain an external database to track user-initiated declines since the API doesn’t natively log these events[5].

Known Limitations

  • A confirmed bug exists where declined shares persist in the Shares directory until manually removed (fixed in later versions)[4].
  • Non-owners can’t delete shares via API - they can only decline them, which doesn’t always update visibility for other users[3][5].

Recommended Actions

  1. Upgrade ownCloud
    Test with ownCloud Server ≥10.14.1 where share state handling has improvements.

  2. Admin Configuration
    Enable these settings in config.php for better share visibility:

    'sharing.enable_resharing' => true,
    'sharing.show_share_with_all_users' => true
    

    This ensures more comprehensive share enumeration[6].

For enterprise deployments, consider implementing a custom middleware layer to monitor share acceptance/decline events until native API improvements are released.