Server: Unable to unshare external share

[skjnldsv]

When deleting a share folder, you can have some invalid shares that cannot be deleted.
It result in an error: Error deleting file "XXXX".

{
  "reqId": "YpITUC2gmR2gsThFxoJt",
  "level": 4,
  "time": "2019-04-25T09:03:56+00:00",
  "user": "USER",
  "app": "webdav",
  "method": "DELETE",
  "url": "/remote.php/dav/files/USER/Shared%20with%20me/XXXX",
  "message": {
    "Exception": "Sabre\\DAV\\Exception\\ServiceUnavailable",
    "Message": "",
    "Code": 0,
    "File": "/var/www/nextcloud/apps/dav/lib/Connector/Sabre/Directory.php",
    "Line": 225,
    "CustomMessage": "--"
  },
  "userAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0",
  "version": "15.0.7.0"
}

I talked with @schiessle and this is the outcome

I just had a look at the code and I think I have found the problem
we need to enter this if statement in order to delete the share: github.com/nextcloud/server/blob/master/apps/files_sharing/lib/External/Manager.php#L525
"share_type" was introduced when we introduced federated group shares to distinguish between group and user shares
so if they have old shares then their might be no share_type and therefore this part of the if statement might evaluate to false: (int)$share['share_type'] === Share::SHARE_TYPE_USER
hope this helps you to debug this further
so you could try to create a share with an old Nextcloud 14 or lower (afaik we introduced federated group shares with 15) then upgrade to 16 and see if the issue can be triggered because of this failing if statement
maybe we need then a repair script which add to all federated shares where this column is empty "0" for user shares. Because all old shares should be user shares

Can I get someone on this? @rullzer @MorrisJobke @blizzz :)

[blizzz]

Scheduled for Wed provided nobody gets to it earlier

[blizzz]

So, I got a {14.0.12, 14.0.4, 13.0.12} running, shared a file to an 16.0.1 instances as remote share (admin@http://172.17.0.3). There, I accepted the share.

Then, i tried to unshare it. But it succeeded. What am I doing wrong to reproduce this?

[skjnldsv]

@blizzz you need to check the tickets I guess :/
Tried with the original share being deleted?

[blizzz]

There was once an issue when the remote server was down, but that was closed as resolved. Deleting should also reach out to the recipient. It might be that, if one host is off in the wrong moment, this won't work. I give it another look later.

[blizzz]

I had to go back to 13, and then after upgrading, share_type was indeed nothing. Unsharing worked without issues though (on 14). Also it seems they used it on the same instance.

[blizzz]

On 14.0.4 (oldest version that instance run on),

1. as userA share folderA as link
2. as userB mount this link share
3. as userA share folderA as local share to userB

@skjnldsv @schiessle let's go that far. Because this is more or less what is happening, I think. At least the entries in the share tables are the same as we receieved.

Then.,

1. upgrade to 15.0.7
2. userB unshares mounted link share

the expectation is that this fails. But it does not.

[maybeec]

This kept being an issue also in Nextcloud 16.0.3.
Nothing to see in nextcloud.log at all.

[skjnldsv]

Ping @blizzz :)

Scheduled for Wed provided nobody gets to it earlier

[StCyr]

I think it's a duplicate of https://github.com/nextcloud/server/issues/14797