Why Did Nginx Return 403? Uncovering Permissions, UMASK, and Jenkins Pitfalls

Background

The release system consists of Jenkins invoking a deployment program (code‑named varian ) that builds a Docker image, pushes it to a registry, and updates a container cluster accessed via a load balancer.

The original varian was a mix of shell and Python scripts with many compatibility hacks, making the codebase messy. A refactor was undertaken to rewrite varian entirely in Python, modularize functionality, and upgrade Jenkins to the latest version with JDK 1.8.

New environment details:

OS: Debian 8

Language: Python 3.4

JDK 1.8 + Jenkins 2.134

Fault Handling Process

Resolving Nginx 403 Errors

After deploying a static HTML project via Jenkins, the web page loaded without styles because the CSS file returned a 403 status. The browser console showed the failed request.

Typical reasons for Nginx returning 403 include:

IP not in whitelist

Directory listing disabled for a directory request

File owned by a user/group without read permission for the Nginx worker user

Incorrect

index

directive (e.g., pointing to

index.shtml

when only

index.html

exists)

In this case the problem was file permissions: Nginx ran as

www-data

, but the CSS file was owned by

root

with no permissions for others.

Understanding Linux File Permissions

<code>-rw-r----- 1 root root 7.9K Jul 24 12:34 csl.css</code>

The first ten characters represent the permission bits. The first character indicates the file type (

-

for regular file,

d

for directory,

l

for link). The next nine characters are grouped in threes for owner, group, and others, with

r

=4,

w

=2,

x

=1.

Owner has read/write (rw‑)

Group has read only (r‑‑)

Others have no permissions (---)

Other fields show link count, owner, group, size, modification time, and filename.

Tomcat8 UMASK Issue

Running the deployment script directly from a Linux console produced files with correct permissions, but the same script executed by Jenkins resulted in incorrect permissions.

Investigation revealed that the generated files inherited the UMASK value of the process. Both the root and Jenkins users had a UMASK of

0022

, which should yield

644

for files. However, Tomcat8 (the container running Jenkins) changed its default UMASK to

0027

, causing the generated CSS file to lack read permission for the Nginx user.

After adjusting Tomcat8’s UMASK back to

0022

, the permission problem was resolved.