Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to log in after restoring from backup. Existing logged-in devices work without issues. #496

Open
csolisr opened this issue Nov 12, 2024 · 3 comments
Labels

Comments

@csolisr
Copy link

csolisr commented Nov 12, 2024

Describe the bug

After restoring from a backup, it's no longer possible to log in using the standard CAS login flow. Existing accounts with a valid login are still able to use the platform unimpeded, but new devices are unable to log in.

Context

  • Hardware: Dedicated x86 computer
  • YunoHost version: 12.0.6
  • I have access to my server: Through SSH, webadmin, direct access
  • Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: yes
    • If yes, please explain: Recently reinstalled from a backup; using an external VPS to bypass NAT restrictions
  • Using, or trying to install package version/branch: 1.117.0~ynh1

Steps to reproduce

  • Restore Synapse and Element from an existing backup.
  • Open a web browser to your Element installation, e.g. https://chat.example.net .
  • Click on "Log in", ensure your base server is correct, then click on "Continue with CAS".

Expected behavior

The standard login workflow should commence, using CAS to validate the user's credentials and then returning to Element's dashboard.

Logs

The site redirects in my case to https://azkware.net/_matrix/cas_server.php/login?service=https%3A%2F%2Fazkware.net%2F_matrix%2Fclient%2Fr0%2Flogin%2Fcas%2Fticket%3FredirectUrl%3Dhttps%253A%252F%252Fchat.azkware.net%252F with an error 404 and the message "File not found."

@csolisr
Copy link
Author

csolisr commented Nov 12, 2024

Just found the error, for some reason the owner for /var/www/synapse were set to be element, not synapse. A quick chown solved the issue for me.

@Josue-T
Copy link

Josue-T commented Nov 20, 2024

Seem to be a bit strange as on the restoration the chown is expected to be done on /var/www/synapse. I can investigate more if you share me the restoration log.

@csolisr
Copy link
Author

csolisr commented Nov 20, 2024

I'll have to search for the restoration log, but I'm not sure if I still have it since it was from last week and it might have been rotated already

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants