SSO Saml users cant delete federated storage

[wwwwiii]

Goodmorning,

Am faceing the following isseu.

I have 2 nextcloud servers that are connected with federated sharing. On the main server i deploy de shares to other nextcloud servers.

All the servers and user recieving the share have full access delete, modify execpt resharing.
The users on de nextcloud server that recieve the share are Azure users users connected with saml 2.0.

Even though those users have full acces they can delete files on the federated share. It counts for webgui and desktop client do difference.

Errors am recieving on desktop client;
Server replied ""500 internal server error to delete "https cloud..."

On de federated user that recieves the share from the main server i see the following errors coming by:

Fatal	webdav	OC\User\NoUserException: Backends provided no user object		2020-04-24T09:41:47+0200
Error	files	Backends provided no user object for [email protected]/

When doing an occ files:scan --all on de same server i see those things popping by:
Protocol negotiation failed: NT_status_Connection_reset

ON the main server where federated shares are located i can delete de folders without any problem.
Both server are freshly installed running ubuntu server 18 lts and running nginx newest nextcloud version

[wwwwiii]

Update seems to be an isseus with nextcloud federated server. I treid sharing with a local user from nextcloud same isseu

[blizzz]

@wwwwiii could it be the same as reported in nextcloud/server#19647 ?

[wwwwiii]

@blizzz Looks a bit the same indeed. Altough there was no solution for that case. We decided to not use nextcloud federated any more cuz it doesnt support cacheing the shared folders...

So every time something is being downloaded it comes from them main server. To much bandwith being used. Am gonna remove the fed and donwload de files to the hypversior from there do an smb mount...

Weird there inst any support for cacheing within federation. I dont think am the first one that requested this.

thx for your reponse.

[blizzz]

Looks a bit the same indeed. Altough there was no solution for that case.

Yes that's true, sadly, however there is the correct place for this report. So I'll close it as duplicate.