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

Add installation step to allow www-data to traverse ~mastodon #1055

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

willia4
Copy link

@willia4 willia4 commented Nov 20, 2022

When running the current installation steps, nginx can't access files in ~mastodon/live and gives the error (in /var/log/nginx/error.log)

stat() "/home/mastodon/live/public/packs/js/locale_en-3ded4a5c02d2d7a36bd0.chunk.js" failed (13: Permission denied)

The easiest way to solve this seems to be adding the +x permission to the base home directory.

Copy link

@helix2301 helix2301 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

using the chmod a+x will a-all and x-execute

gives all users the execute bits to the home drive

Is there a better way for security wise to do this?

@jenbanim
Copy link

jenbanim commented Dec 31, 2022

I'm not confident this is the best option, but what I did was add the www-data user to the group mastodon and then set the permissions on the mastodon home directory to 750 (user gets read-write access, group gets read-only access, others get nothing)

gpasswd -a www-data mastodon
chmod 750 /home/mastodon

Nginx runs its processes under the user www-data and the /home/mastodon directory is owned by the group mastodon by default, so what this does is gives nginx read-only permissions to the /home/mastodon directory

I can't really imagine a situation where nginx having write permissions would be a concern, but this seemed prudent

@aaaaalbert
Copy link
Contributor

See also #1128 and the linked PRs (chmod o+x there).

Your proposed solution based on group accesss rights is probably a better -- i.e. tighter -- fix, particularly on non-dedicated machines.

@mihalis68
Copy link

The suggestion from @jenbanim worked for me and seems the best - agreed. How can we get this into the official docs? I just built my second instance and had to scrabble around a bit before I found this fix again.

@vmstan vmstan requested a review from a team November 29, 2023 19:00
@vmstan vmstan mentioned this pull request Nov 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants