A file the web server cannot write is usually fixed with 777, and it works. It also means any process on the machine - including one an attacker just uploaded - can rewrite it. The real question is not what the permissions are but who owns the file.

The correct arrangement

sudo chown -R sara:www-data /var/www/site\nsudo find /var/www/site -type d -exec chmod 2750 {} \;\nsudo find /var/www/site -type f -exec chmod 640 {} \;\n\n# only what genuinely must be written\nsudo chmod -R 2770 /var/www/site/storage /var/www/site/uploads

You own the files, the web server owns the group, and it can read everything and write only the two directories that need it.

The leading 2 is the group trap

That is setgid. Without it, a file created inside the directory takes the creator's own group, so a file uploaded by the web server is not readable by you - and one you create is not writable by it. Everything works until somebody else adds a file, which is why the fault seems random.

sudo chmod g+s /var/www/site/uploads\nls -ld /var/www/site/uploads      # drwxrws--- - the s is the setgid bit

umask decides what NEW files get

umask            # 0022 typical: new files 644, new dirs 755\numask 0007       # files 660, dirs 770 - nothing for others

Set it in the service unit for a daemon, not in your shell profile, or it applies only to files you create by hand.

# /etc/systemd/system/app.service\n[Service]\nUMask=0007

Never 777

777 on an uploads directory plus a web server willing to execute PHP there is the single most common way a site is taken over. See uploads directory: never executable.

Find what is already wrong

find /var/www -perm -o=w -not -type l | head -20