Nginx Access Error Caused by File Permissions

Recently, personal image upload tool uploaded images, when HTTP access failed, all reported 403. Initially thought it was nginx anti-hotlinking settings, but finally determined the direct cause was insufficient file permissions.

Recording this problem here

About 403

Status code 403 Forbidden represents client error, meaning the server has ability to handle the request, but refuses authorization access.

This status is similar to 401, but after entering this status, verification cannot continue. This access is permanently prohibited and closely related to application logic (e.g., incorrect password).

• 401 and 403 are similar, but still different. 401 is login not successful, while 403 has login identity but partial permissions insufficient.

FS-ACL

After analysis, located that this 403 is caused by nginx container insufficient permissions to access file resources. As shown, files SCP’d to server show permissions as 600, meaning only owner root has read/write permissions. But nginx requests access to image static resources as nginx user, therefore doesn’t have read permission.

Solution is to grant file group/other users read permission. For example 644

SCP, Rsync

My image upload here uses self-written upload tool, so need targeted solution.

For upload tool, I used SCP command, found SCP doesn’t support modifying file permissions, so had to switch to Rsync, specific code as follows

rsync -p --chmod=Du=rwx,Dgo=rx,Fu=rw,Fog=r ./temp/{query} $user@$server:$destination/$year

Notes

• scp parameter -p preserves file permission modes, not referring to file ACL, so doesn’t work
• rsync’s -p can preserve file permissions, so can use, but here because I also need to ultimately modify file permissions, added chmod
• Above chmod configuration effect is folders 755, files 644

Final Thoughts

• After above modifications, re-uploaded resources, fixed

• Whenever encountering SCP file upload while file permissions need adjustment, can consider switching to Rsync

• Always thought nginx reporting 403 would be container layer triggering anti-hotlinking/or backend business code reporting insufficient permissions, now one more possibility: container itself insufficient permissions when accessing server storage resources.