@james Hi, First of all, thank you very much for taking the time to respond to my question and provide a solution to my issue — I really appreciate it! In the end, I managed to log in to Mastodon by manually creating an admin user. Here’s the command I used inside the Mastodon directory: RAILS_ENV=production bundle exec rails console << 'SCRIPT' user = User.new(email: 'user@example.com', password: 'StrongPassword123!', password_confirmation: 'StrongPassword123!', agreement: true, confirmed_at: Time.now.utc) user.account = Account.new(username: 'username') user.save! user.approve! user.update(role: UserRole.find_by(name: 'Owner')) puts "User created successfully: #{user.account.username} (#{user.email})" SCRIPT Only after creating the admin user this way, I was able to successfully access Mastodon. Best regards, Yossi

Thanks! as it turns out, in my case it was the cloudflare proxy causing issues. I had disabled it for IPv4 but forgot to do the same for IPv6 so the results/errors were confusing because of this.

Oh sorry, just saw this. I guess what I'm confused by is the fact that at some point I made an edit to the core app and that modification did (and does) persist. ... which is to say that if the system to revert changes has been around since... early June/late May, then I think I inadvertently found a way around it (that I admittedly can't replicate). Since I can't reliably replicate the change, I guess there's no need to investigate or consider it further, especially if the code-reversion thing is a new addition (which would explain why I was able to modify my instance up until a few weeks ago, but not now). But I will +1 to the desire to be able to make modifications to core applications (even if we have to affirmatively take responsibility for crashing it, or at least have backups in place). I realize the net balance of benefits vs costs might never support it though. In any case, thanks for the reply, I appreciate it.

It looks like the migration went smoothly. I'll put together a blog post to details the steps I took. Thank you again for all the help!

Hello @sponch There are currently no plans to include this in the Cloudron Package for Mastodon.

If you continue to read the aws-cli docs, you can specify where to install them, ie /app/data It's alsways useful to set the HOME dir variable whenever working with the CLI with export HOME=/app/data

@robi Good idea, thanks. Continuing in https://forum.cloudron.io/post/105874

@scooke @jdaviescoates Ok, I will look into the storage factor before I applied any fakerelay. Thank for the advice.

@joseph Thank you for your feedback. So far, my setup has been working well for a month. But I will follow your advice and use the hosts file to avoid updates breaking my setup.

But it will force me to maintain the old instance. OK. Thank you for your help

Hey all, thanks for recent notes. Still a good idea, probably need to find a developer who can do the packaging first.

I seem to recall that there may be tools out there to help this, but your googling will turn up whatever that was just as quick as mine. I would say that I tried doing this myself, twice, and by the second time I decided to handle it manually. That is, I downloaded and saved (I know, I should have done better saving the originals) the various graphics my site used, as well as my list of contacts, etc., and then re-uploaded them to the new location, then relinked them from within Mastodon. The first time the migration didn't work, there was no one who could help, and it was just quicker to do it manually. All the graphics connected to other users were eventually repopulated anyway, and anything I had wanted previously I had downloaded and saved. So, in a way, there wasn't a need to migrate anything. Good luck.

@jayonrails the avatar link is set in the OIDC responses. that's the only situation where cloudron's profile pics are used in apps.

the second link (everything on the second link)

right I meant more like the app was maybe installed from a package, where the OTP_SECRET was not yet set properly. This was then a packaging bug not a user error.

Thank you for the explanation, I didn't know that.

@johannesjom me too

here we go Using a private bucket on Hetzner. S3_ENABLED=true S3_BUCKET=NameOfYourBucket AWS_ACCESS_KEY_ID=xxxxxxxx AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxx S3_REGION=eu-central-1 S3_PROTOCOL=https S3_HOSTNAME=NameOfYourBucket.fsn1.your-objectstorage.com S3_ENDPOINT=https://NameOfYourBucket.fsn1.your-objectstorage.com

While typing this here, I had the idea to check the create command for a flag and indeed there is --approve: /app/code/bin/tootctl accounts modify testusername --approve