It depends on which user the web server runs as, that has to have rw permissions on files (write at least during updates through the frontend) and rwx on directories (at least in and under piwigo/{_data,upload} directories and write all for updates). What the actual permissions best should be can't be answered without knowing details. If 755/644 doesn't work for you then your account user is different from the web server user (common if both aren't chroot'ed to the same user). If the web server is a user of the group assigned to files then permissions for you could be 770/660 (as other wouldn't need any permission). If it is yet something different and needs other for permissions then it could be 707/606 (if group isn't needed, else 757/646 or even 777/666) but that write permission for other is rather ugly if on shared hosting that was setup carelessly. Best ask your hosting provider if you don't know. Last but not least theoretically also ACL (Access Control List) permissions could be in use.

See also [Forum, post 180666 by erAck in topic 28678] Http Error 500.

I thought I explained it. What is so unintelligible about "can't be answered without knowing details"?
You didn't tell what user the web server runs as and how that fits into your owner/group/other situation.
Maybe 775/664 works for you, maybe not. If not then stick with 777/666, you didn't tell whether you are on a shared hosting either nor if other users could even access your files.

Having owned everything by (and working as) root is a bad idea.

Whether 777/666 is safe or not depends on your environment and threat model. If there are other user accounts having access they can mess around.

Unfortunately the "web served files need only be read-only" doesn't hold for Piwigo {_data,upload} but you can place (see $conf['data_location'] = '_data/'; configuration directive) or symbolic link those directories elsewhere where you're comfortable with having write access. An overall write access is needed for updates through the web frontend anyway, which of course can also be granted individually only before an update and revoked after.

Other solutions: if your web server is, for example, running as user nobody then change ownership of all files and directories under the DocumentRoot to nobody and get away with 755/644 permissions or 600 for files that shouldn't be readable by anyone else like local/config/database.inc.php. You'll have to remember to do that for new directories you create manually so the web server user can write to those, content created by the web server and PHP scripts works as is.

Another is, have a dedicated user which you use for work to own files and directories, assign group www-data (if Apache) recursively to /path/to/htdocs/your-documentroot/ and set the SGID bit on directories recursively as well so new files and directories inherit the group. Permissions then would be 775/664 or 660 for files that shouldn't be readable by anyone else like local/config/database.inc.php. Directories/files created by the web server will have its user as owner, so to work on them as your other user ownership may have to be reassigned.

Example commands to start with this (have to be executed as root once):

chown -R youruser:www-data /path/to/htdocs/your-documentroot
find /path/to/htdocs/your-documentroot -type d -exec chmod g+ws {} \;

More fine grained control can be achieved by using ACLs, see for example https://www.redhat.com/sysadmin/linux-a … trol-lists or https://www.thegeeksearch.com/beginners … -in-linux/