Something happened. Unable to accept the share


Nextcloud version: 25.0.4snap1
Operating system and version: Ubuntu 18.04.2 LTS
Apache or nginx version: Apache (fpm-fcgi) I don’t know how to view his version
PHP version: 8.1.16

The issue you are facing:

I have the latest snap version of nextcloud. The update is automatic. Users and groups are pulled from AD.
The problem is: access restriction based on local groups works, but based on groups from AD does not work. A user accessed through an AD group gets an invitation to accept this access, but the “accept share” or “reject share” buttons just don’t work. When clicking on them you get the message “Something happened. Unable to accept the share.”.
I searched the forum and found old threads from 2019 that described a similar problem. There were links to a githab that suggested to manually fix the nextcloud code. But as I understand, after the next automatic update these edits will be rewritten…

Is this the first time you’ve seen this error? :

Yes, I just recently enabled the import of groups from AD

Steps to replicate it:

  1. Give access to the share to the group from AD.
  2. A member of this group goes to Shares, Pending shares, and sees an invitation to “accept share”, clicks on it
  3. Gets the error “Something happened. Unable to accept the share.”

The output of your Nextcloud log in Admin > Logging:

what level of logging is required? 

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

    "apps_paths": [
            "path": "\/snap\/nextcloud\/current\/htdocs\/apps",
            "url": "\/apps",
            "writable": false
            "path": "\/var\/snap\/nextcloud\/current\/nextcloud\/extra-apps",
            "url": "\/extra-apps",
            "writable": true
    "supportedDatabases": [
    "memcache.locking": "\\OC\\Memcache\\Redis",
    "memcache.local": "\\OC\\Memcache\\Redis",
    "redis": {
        "host": "***REMOVED SENSITIVE VALUE***",
        "port": 0
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "dbtype": "mysql",
    "version": "",
    "overwrite.cli.url": "http:\/\/***.***.***",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbport": "",
    "dbtableprefix": "oc_",
    "mysql.utf8mb4": true,
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "installed": true,
    "mail_from_address": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpmode": "smtp",
    "mail_sendmailmode": "smtp",
    "mail_domain": "***REMOVED SENSITIVE VALUE***",
    "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpport": "25",
    "twofactor_enforced": "false",
    "twofactor_enforced_groups": [
    "twofactor_enforced_excluded_groups": [],
    "ldapIgnoreNamingRules": false,
    "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
    "maintenance": false,
    "loglevel": 0

Having the same issue here, and currently on Version 26.0.0

The entries below show up in my Aapche logs when clicking “Accept Share” or “Reject Share”. The first is from clicking Accept, and the second from clicking Reject.

==> nextcloud.domain-access.log <== - - [07/Apr/2023:21:26:23 -0700] “POST /ocs/v2.php/apps/files_sharing/api/v1/shares/pending/2 HTTP/1.0” 404 1180 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0” - - [07/Apr/2023:21:26:29 -0700] “DELETE /ocs/v2.php/apps/files_sharing/api/v1/shares/2 HTTP/1.0” 404 1180 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0”

Hi. Were you able to solve the problem?

I ended up making so many changes while troubleshooting this, I couldn’t say specifically which ones solved my problem. But I’ll try to list everything I did.

After setting up LDAP group sync and looking at the groups in NextCloud, the group names were there, but they were always empty. I could go to Active Users and see the LDAP users and their respective group memberships, but if you looked at individual groups on in the left sidebar, the right pane was empty.

I made the following changes.

LDAP/AD integration → Server
Base DN - CN=Users,DC=contoso,DC=com

LDAP/AD integration → Users
Only these object classes - person

I also setup a security group that contains only the users I want synced into Nextcloud, but do not think that change is related to this problem.

LDAP/AD integration → Advanced → Directory Settings
User Display Name Field - displayname (I think this is the default)
Group Display Name Field - cn (the default)
Group-Member Association - member (AD) (this is empty by default)
Base User Tree - DC=contoso,DC=com
Base Group Tree - DC=contoso,DC=com

LDAP/AD integration → Advanced → Special Attributes
Email Field - mail (this is empty by default)

As I recall it was the Group-Member Association that got my groups to be populated properly.

LDAP/AD integration → Expert → Internal Username
Internal Username Attribute - sAMAccountName (the default is blank, and I believe it uses the UUID attribute, but my notes are a bit light on that one. Regardless, the default create users and homedirs in Nextcloud with GUID strings, which looks gross in the nice UI. Switching to sAMAccountName made users in NC match their LDAP accounts.)

After all of the changes, sharing started to work, and did not require the recipient click Accept Share.

So, I made a bunch of changes, and now my sharing works. I hope at least something in that mess helps you.

1 Like

Thank you very much for your detailed response
I will definitely try to reproduce your steps in my working environment, but it seems that I have a slightly different problem: for my users, clicking on the “accept share” button itself has no result whatsoever. The same result for “reject share”.

Although, maybe if your method works and users don’t have to click that button… then the end result will be obtained. Yes, that makes sense.