broken federated share leads to the recepient server bugging out #12175
Comments
jcklpe
changed the title
|
GitMate.io thinks possibly related issues are #4961 (Accepting federated share is broken), #4844 (Suggest servers to trust based on existing federated shares), #3908 (Give proper feedback when server has disabled federated cloud sharing), #11667 (Federation shares ignore server ports), and #3001 (Bug after Update from NC10 to NC11: Sharing with users breaks ). |
|
Hmmm.... not sure what happened but it just started working again. I was looking through some issues for that guzzle http error and a guy said he ran app:disable files_external_gdrive and it started working. Well I have that on my machine but I'm not using it for anything. So I disabled it. And stuff is working now? But it could be unrelated. Because if I renable it, the thing keeps working. I do see in my notifications there's still that notification for accepted the share request. Maybe disabling the files_external command jogged the system and it unaccepted it or something? Here's what the notification looks like:
It says [email protected] which seems to indicate to me that at the time of me sending out that share it wasn't actually running off the public IP etc, it was sending it as some kind of LAN address which is obviously not accessible to my computer which is external, I guess? Also checked the admin logs on the web portal and found this: So I hit decline the share request and I get this error: And then the notification pops up again! So I hit accept and I get this response: This time though my webserver didn't become dysfunctional. So that's good... but I'm still confused on what caused this, or how I even fixed it? |
|
Oh wait... so I got to the apps page under admin to take a look at the file_sharing app and it gives me the internal error. Then I refresh.... and works? Huh? For that I got this log: |
skjnldsv
added
the
0. Needs triage
|
Still an issue? |
|
@kesselb As far as I know it is. I ended up having to go into my database and manually delete reference to the federated share so that it wouldn't bug out like this. |
|
Had to do the same, just followed #3766 (comment) |
skjnldsv
added
1. to develop
|
Any ETAs on when this bug will be fixed? |
How can I do that if I am using sqlite inside the docker edition? No sqlite client is included, only libs and integration for php. |
I agree with that idea. |
|
I ran into this problem today, it was for a share that I've added in the past, and it was to a different NextCloud account on the same server. This must just be a very hard to reproduce fluke. Since I am not the administrator, I cannot just modify the database. And I'm not sure if the administration is going to be keen on taking everyone's NextCloud servers offline to make the described correction. If a command just existed that would let me fix it, I could pass it into the OCC Web plugin and everything would be fine. |
|
I finished solving it using sqlite3 client, with the volume mounted previously, and deleting the problematics rows in the table oc_share_external by id. |
@daita Given you've been working on code related to federated shares, is there any chance you'd be willing to look into this for us? Having to bring down the entire server and manually delete entries from the database is just not practical. |
|
if someone could point me to the location where the federation app's occ commands are in the source I might be able to add this and create a PR. Should be doable, I was just unable to find the palce in the source :( |
|
Just here to say that I have the same Issue, tho my UI never crashed so far. (Version 19.0.3) |
|
This is still a pressing issue. I just had a share that was working before break for no reason in particular (which is weird because the source is still up and won't let me add it because it thinks I already have access), and yeah, this is a hosted instance of NextCloud so I can't just bring it down and fix the database. The 'OCC Web' app does work even on the latest beta version of NextCloud, so I could potentially use that, but a command to force remove a share has to be added first. |
|
I have the same issue. It is a real problem.... |
|
+1 to the issue; SQL modification is a bit cumbersome. What's the best way the community can help to solve this permanently? I can think of two options:
|
|
Hi, please update to 24.0.8 or better 25.0.2 and report back if it fixes the issue. Thank you! |
szaimen
added
needs info
0. Needs triage
|
Is this fixed in the sense that broken federated shares can explicitly be deleted through the web UI? |
How to use GitHub
Steps to reproduce
Expected behaviour
Idk, but it seems that I should at least be able to unshare or delete the incorrectly performing federated share instead of it basically crashing my admin user.
Actual behaviour
Server configuration
Operating system: Ubuntu 18.04
Web server: nginx/1.14.0 (Ubuntu)
Database: 10.1.34-MariaDB
PHP version: PHP 7.2
Nextcloud version: Nextcloud 14.03
Updated from an older Nextcloud/ownCloud or fresh install:
Where did you install Nextcloud from: from Nextcloud website.
Signing status:
Signing status
Sorry, but I do not understand what the above is asking or referring to?List of activated apps:
sudo -u www-data php occ app:list Enabled: - accessibility: 1.0.1 - activity: 2.7.0 - admin_audit: 1.4.0 - admin_notifications: 1.0.2 - audioplayer: 2.4.1 - bruteforcesettings: 1.1.0 - cloud_federation_api: 0.0.1 - cms_pico: 0.9.7 - comments: 1.4.0 - dav: 1.6.0 - dropit: 0.1.1 - federatedfilesharing: 1.4.0 - files: 1.9.0 - files_accesscontrol: 1.4.0 - files_automatedtagging: 1.4.0 - files_external: 1.5.0 - files_external_gdrive: 0.2.8 - files_pdfviewer: 1.3.2 - files_rightclick: 0.8.4 - files_sharing: 1.6.2 - files_texteditor: 2.6.0 - files_trashbin: 1.4.1 - files_versions: 1.7.1 - files_videoplayer: 1.3.0 - gallery: 18.1.0 - groupfolders: 1.3.3 - impersonate: 1.1.0 - logreader: 2.0.0 - lookup_server_connector: 1.2.0 - music: 0.9.2 - nextcloud_announcements: 1.3.0 - notifications: 2.2.1 - oauth2: 1.2.1 - password_policy: 1.4.0 - provisioning_api: 1.4.0 - quota_warning: 1.3.0 - ransomware_protection: 1.2.0 - richdocuments: 2.0.13 - serverinfo: 1.4.0 - sharebymail: 1.4.0 - sharerenamer: 2.2.0 - spreed: 4.0.0 - support: 1.0.0 - survey_client: 1.2.0 - systemtags: 1.4.0 - theming: 1.5.0 - theming_customcss: 1.1.0 - twofactor_backupcodes: 1.3.1 - updatenotification: 1.4.1 - workflowengine: 1.4.0 Disabled: - encryption - end_to_end_encryption - federation - firstrunwizard - user_external - user_ldap
Nextcloud configuration:
Config report
Are you using external storage, if yes which one: local
Are you using encryption: no
Are you using an external user-backend, if yes which one: no
Client configuration
Browser: Chrome and Firefox
Operating system: Windows 10 and Ubuntu 18.04
Logs
Web server error log
Web server error log
Nextcloud log (data/nextcloud.log)
Nextcloud log
Troubleshooting process
I tried troubleshooting this for awhile using the forums and looking up documentation on my own.
Here's a link to the discourse thread I started trying to figure this stuff out: https://help.nextcloud.com/t/accepting-a-improperly-configured-federated-share-has-made-my-server-impossible-to-access/40094
In Summary: I tried setting up a server for my parents. From their server I sent a federated share request. I still haven't figured out what is wrong with their server, but it's not possible to access it externally. I think this is because the ISP is blocking port 443 despite me setting up port forwarding rules on their router. (EDIT: I have confirmed that this was the problem with their server. I have gotten around it by setting up an open port at 8443 which has to be specified in order to reach the webpage which is very annoying, but there's nothing I can do about it).
When I logged back into the web interface for my server, which was working fine, I saw a notification asking for me to accept the federation share. I did so, and then the server blew up as shown above.
I tried disabling the federation app, but I was unable to disable the federation_sharing app. The issue went away for about a day and then it came back. I don't know why or what caused this. My parents, unbeknownst to me turned off their server because it wasn't working. They turned it back on yesterday. So I think maybe what happened is that when it was turned off, I accepted, the server wasn't there and/or was misconfigured so it bugged out. Then after a cron job or something it got to working again, but then when they turned it back on it bugged it out again. Or something. IDK. It's hard to say.
Other perhaps useful info. I can access the web frontend by going to localhost, perhaps because under localhost admin is not auto logged in. If I try to log into admin while under localhost it gives me a similar bug as when I try to access it through my normal web domain.
I can not seem to make heads or tails of this. I seemed to have found multiple related errors that people have experienced but according to the github responses these issues were addressed and fixed. But obviously not in my case. I have commented on these threads asking for additional information or help and have not heard back so I decided to log this fresh issue here.
Here are a few of the issues that seem like they might be related:
I also tried running files:scan and I get the following output:
And in writing up this issue I tried to install the Issue Template app by command line so that I could cut down on all the copying and pasting and I got the following output:
The text was updated successfully, but these errors were encountered: