Setting permissions with Upgrader

[Gryzor]

So I just did a clean install of 2.1.3 and I was wondering this:

I'm probably having permission issues, and the installation instructions say that the Upgrader script can take care of the permissions subject. However I didn't see such an option - or is it done silently?

It seems that the Permissions manager in the Admin section cannot change permissions - any ideas as to why?

[Aleksi "Lex" Kilpinen]

I haven't actually experimented with the upgrader enough to comment on that part, but what makes you think you have permission issues to begin with?

[Gryzor]

Well, mods refuse to install, and the permissions manager shows me some directories as not writeable... 

[Aleksi "Lex" Kilpinen]

You should be able to check both the permissions and ownership through your hosting control panel or FTP client (such as FileZilla). If it's simply a permission issue, you should also be able to change permissions through both - If on the other hand it's an ownership issue, then you may need to ask your host to help change the file/folder owners.

[Illori]

if the directories are not writable, most likely the upgrade script cannot access them to fix the permissions. you would have to fix them manually.

[Gryzor]

Thanks to you both. All dirs are owned by www-data, but I've been having problems for ages, for reasons I can't understand.

In the end I'll mass-adjust in terminal, but I was wondering if there was a way from within the forum itself.

755 and 644 for folders and files respectively, I guess? 

[Aleksi "Lex" Kilpinen]

If you upload an attachment, or turn on file based caching, are the resulting files on the server also owned by www-data? If not, then you have a configuration issue. Most commonly, things would be configured so that you the user are the owner.

[Gryzor]

I'll check out ownership of uploaded files and report back. 

Should the files really be owned by my user? I was under the impression this is not a correct tactic (then again, I'm faaaar far away from being a linux expert).

[Aleksi "Lex" Kilpinen]

The actual user is sort of besides the point, but both apache and PHP can be configured separately and should preferably be the same to work together

[Gryzor]

Yeah, I think I see what you mean. What puzzles me is how some things work and some won't, though... Really weird. 

[Aleksi "Lex" Kilpinen]

If apache and php are not running with the same user, the workaround would be to make the files 777 manually when ever you need to install mods or make changes to files in SMF. The fix would be to change the setup, for php-fpm the default user is nobody:nobody, for apache the default user is www-data:www-data, these don't work together as is because they are not allowed to touch each other's files.

[Gryzor]

Just had the time to go over your reply properly. If I'm reading the last part correctly, apache and PHP need to use the same user?

Edit: as far as I can see, both apache and php run under www-data:www-data.

All my folders are 755, all my files 644. Yet installing/uninstalling mods fails spectacularly... any ideas what to look for next?

[Aleksi "Lex" Kilpinen]

Do you see any errors in your server's error log when you try to use the package manager?
If apache and php are using the same user, and the files are owned by that same user, then permissions isn't the issue.

[Gryzor]

Apologies for the late reply, didn't have the time to look into it...

Logs didn't show anything really enlightening. PHP and apache run under the same user indeed.

However, I managed to solve my issues; seems like it *was* a permissions issue, even though I had not changed a single thing and I had also tried enforcing permissions manually to various folders like Sources or temp to 777.

Anyhow, I decided to take a step back and applied 755 to all folders and 644 to all files in the shell, even though the SMF permissions manager showed everything was fine. And guess what, everything runs smooth now...

For anyone looking for similar issues, these are the commands I used as root:

Code Select Expand

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Warning, this took several minutes to complete on my server since after many years of running SMF we had accumulated quite a few folders and files.

Hope these settings do not constitute a security hole...

Thanks for the help, Aleksi!

[Kindred]

755 and 644 are not security holes.

[Gryzor]

755 and 644 are not security holes.

Yes, I wouldn't think so, it's the blanket setting the permissions that got me a little nervous. 

[Kindred]

why? 755/644 literally are the correct settings to run a system so that the core system/user can properly access files.

[Gryzor]

why? 755/644 literally are the correct settings to run a system so that the core system/user can properly access files.

Because although that's what I know, too, I'm not an expert on Linux security. Nothing specific, just newbie anxiety😁