I uploaded a folder of new pages to my shared hosting account, refreshed the site, and got a 403 Forbidden on every single one of them. The files were all there. The HTML was fine. The paths were right. Nothing had changed in the code — only the permissions.
The upload had come from a zip file. I had extracted it in the file manager, and every folder it created came back with permissions 750 instead of 755. That one missing digit was the whole problem, and it took me longer than I would like to admit to spot it.
What 750 actually means
Unix permissions are three digits: owner, group, and everyone else. 755 means the owner can read, write and enter the folder, and everyone else can read and enter it. 750 means the owner and the group can, but everyone else gets nothing at all.
On shared hosting, that last digit matters more than people expect. Your files are owned by your account, but the web server process that serves them to visitors usually runs as a different user. If the folder is 750 and the server is not in your group, the server cannot even look inside the folder. It does not matter that the files inside are 644 and perfectly readable — the server never gets that far. It hits the folder, gets denied, and returns a 403.
That is exactly what happened to me. The files were fine. The door to the room was locked.
Why extraction does it
When you extract a zip on your own computer, the folders usually keep whatever permissions they were packed with, and your user account owns everything, so you never notice. On shared hosting, the file manager extracts as your account user, and the permissions in the archive win. Plenty of zips — especially ones built on Windows or packed by a build script that never thought about it — carry 750 on their folders, or carry no permissions at all and get the server's default umask applied, which can land in the same place.
The confusing part is that it is inconsistent. Some folders come out 755 and work. Others come out 750 and break. It depends on how each folder was packed, so a deploy can look half-broken: the homepage loads, three new pages 403, and nothing in the error log points at the real cause beyond a generic permission denied.
How I check it now
My deploy checklist for ramrom.io now has one boring line on it: after every upload, check the folder permissions before checking anything else. In the file manager I select the uploaded folders and look at the number. Folders should be 755, files 644. If a folder shows 750, I change it to 755 and the page comes back immediately — no re-upload, no code change, no waiting.
If you have shell access, the same check is one command:
find . -type d -perm 750 That lists every folder with the problem. Fixing them is just as short:
find . -type d -exec chmod 755 {} + I run the check rather than the fix blindly, because a folder that is deliberately 750 — say one holding config files that should never be served — is 750 on purpose. The config directory on my site is exactly that: blocked from the web on purpose, and I never want a bulk chmod to open it up. So the rule is: find the 750s, look at each one, and only open the ones that are meant to be public.
The lesson that stuck
A 403 after a deploy does not always mean your code is broken. Sometimes it means the web server simply cannot reach the files you just gave it. Before I touch a line of code or re-upload anything, I check permissions first. It is a thirty-second check that has saved me from chasing a bug that was never there.
The annoying bugs are rarely the clever ones. They are the ones where everything looks right and one small number is wrong.
