Error while upgrading Mastodon: `Uhoh, unknown permission mastodon.main`

My YunoHost server

Hardware: VPS bought online
YunoHost version:
I have access to my server : Through SSH
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : Yes, I’m fresh after updating to yunohost 11

Description of my issue

I was upgrading Mastodon, and the upgrade failed due to some permission issues:

Uhoh, unknown permission mastodon.main ? (Maybe we're in the process or deleting the perm for this app...)

Then Yunohost tried to revert the backup of Mastodon, but it failed, so I ended up with no working Mastodon version.

Here’s the full log:

BTW, I seem to be getting this “something is wrong with permissions so yunohost fails disgracefully” sometimes, but I don’t see the problem reported elsewhere. Could there be something that I’m doing wrong that’s causing that to happen? See Failed synapse upgrade for context

The actual issue for the failed upgrade is :

2023-01-05 17:36:12,513: DEBUG - + sudo -u mastodon RAILS_ENV=production PATH=/opt/rbenv/versions/mastodon/bin:/opt/node_n/n/versions/node/16/bin:/opt/node_n/bin:/opt/rbenv/shims:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LD_PRELOAD=/usr/lib/x86_64-linux-gnu/ bin/bundle exec rails assets:clean
2023-01-05 17:36:18,615: DEBUG - rails aborted!
2023-01-05 17:36:18,615: DEBUG - LoadError: Could not open library '/var/www/mastodon/live/vendor/bundle/ruby/3.0.0/gems/blurhash-0.1.6/lib/../ext/blurhash/': /var/www/mastodon/live/vendor/bundle/ruby/3.0.0/gems/blurhash-0.1.6/lib/../ext/blurhash/ cannot open shared object file: No such file or directory

which I’ve seen elsewhere reported by other people …

Then during the remove-after-failed-upgrade, we see:

2023-01-05 17:36:59,008: DEBUG - [###########++.......] > Removing app main directory...
2023-01-05 17:42:15,091: WARNING - rm: cannot remove '/var/www/mastodon': Device or resource busy

maybe because the service was still running / file used by some program, idk :confused:

and therefore during the restore-after-failed-upgrade it failed because /var/www/mastodon already existed:

2023-01-05 18:00:17,639: DEBUG - 1077018 + test '!' -d /var/www/mastodon
2023-01-05 18:00:17,639: DEBUG - 1077019 + ynh_die '--message=There is already a directory: /var/www/mastodon '
2023-01-05 18:00:17,668: DEBUG - 1077044 + echo 'There is already a directory: /var/www/mastodon ' 

Soooo that doesnt help much but this seem to have nothing to do with permissions

I think maybe if you manually delete the old /var/www/mastodon, maybe the restoration can work this time

The /var/www/mastodon directory is a mount root for an external volume, I can’t delete it. Is it possible to just have yunohost check if it’s an empty dir and proceed? I don’t have enough free space to make yuno install Mastodon on the root filesystem

Ugh I see …

I think one workaround would be to mount the external volume as /var/www/ instead of just /var/www/mastodon, but that may imply too many file movement if you have already a bunch of other apps installed

The other way would be to edit the app restore script inside the archive to remove the test ! -d $final_path check :confused:

I’m going to remount the /var/www directory as another external volume, move the files there, and see how it goes :+1:

This helped. The app was restored. The app didn’t want to start, though. I was getting

/var/www/mastodon/live/vendor/bundle/ruby/2.7.0/gems/ffi-1.10.0/lib/ffi/library.rb:112: [BUG] Segmentation fault at 0x0000000000189dc8
ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]

Thanks to this blog post I now fixed this by adding Environment="" to

  • /etc/systemd/system/mastodon-web.service,
  • /etc/systemd/system/mastodon-sidekiq.service and
  • /etc/systemd/system/mastodon-streaming.service

and restarting the mastodon-web, mastodon-streaming and mastodon-sidekiq services.

Also, some .so files within gem directories were missing. I had to go there and run make manually to create those

1 Like

This helped me to remove the original files in /var/www from the original partition after the new one has been mounted:

Also, remember to copy the hidden .well-known directory from /var/www, as it’s not caught by the /var/www/* glob!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.