PGID/PUID Settings

[SimonMischenkoHawk]

Describe the bug
When I force FileRise to run as --user 99:100, the container’s startup script (start.sh) fails with multiple “Permission denied” errors while trying to write its Apache/PHP config files under /etc. As a direct result, the container crashes/exits. I think the init script still runs as root and expects to be able to modify /etc, so dropping privileges too early breaks startup. This is a bit of an issue on Unraid, as running without PGID/PUID 99:100 (nobody:users) does not by default allow access to any 99:100 files in appdata directories, for example, and recursively expanding permissions on entire appdata directories is considered bad practice for security (as well as usability in a few instances). Is there a correct way to run the service as a specific PGID/PUID, or is this unaccounted for right now? Without this ability, FileRise is somewhat practical for file upload in empty directories but not file traversal in actively used directories since local system files are invisible/inaccessible.

To Reproduce
Steps to reproduce the behavior:
In the Unraid Docker template for FileRise, enable Advanced View.

Under Extra Parameters, add:
--user 99:100
Apply / start the container.
Check the container logs; you’ll see errors like:
/usr/local/bin/start.sh: line 42: /etc/php/8.3/apache2/conf.d/99-custom.ini: Permission denied
/usr/local/bin/start.sh: line 69: /etc/apache2/conf-enabled/limit_request_body.conf: Permission denied
…and so on…

Expected behavior
I expected that setting --user 99:100 would allow FileRise to run entirely as UID 99/GID 100, adjusting any needed file permissions automatically, without startup failures.

I figured either:
Run its Apache/PHP config steps as root and then drop to filerise user for the web server, or
Respect the PUID/PGID env‑vars and chown the /etc files appropriately before writing.
etc

In any case, I would hope to see system files without making sweeping permissions edits (Ones that, if we're being honest, most users probably don't understand or audit as well as they should for security purposes).

Desktop (please complete the following information):

• OS: Windows 11
• Vivaldi
• error311/filerise-docker:latest

[error311]

Thanks for flagging this, @SimonMischenkoHawk

You’re absolutely right. Forcing the container to run with --user was my mistake. Instead of overriding the container user, FileRise now respects PUID/PGID environment variables. If you remove the --user flag and set your desired UID/GID via PUID/PGID, the startup script will run as root (so all /etc writes succeed) and Apache will drop into your unprivileged user for file access.

[error311]

Changes:

Unraid Template: error311/UNRAID_COMMUNITY_APPS@564d595

FileRise Dockerfile:
6ff4aa5
ca3e2f3

[error311]

Thanks again for the report, @SimonMischenkoHawk.
Please give the latest image and template a spin, and let me know if you encounter any further issues—happy to reopen or iterate as needed.

[SimonMischenkoHawk]

This is a huge improvement! I can't even begin to describe how much I will be thrilled to replace FileBrowser with FileRise as my daily driver given the number of large-transfer problems I've had with the former. Thank you for your work on this project.

Re: the latest image- I notice at least one annoying/usage limiting bug in the new version that might otherwise warrant a new ticket- I'm happy to make one if you prefer.

When looking at the file search textbox

No matter how many times I remove the contents of the textbox, it pops back with my user account name immediately after deleting all text. I believe this is actually a browser interaction, as I can't replicate it on Edge but it happens on Vivaldi. When I have saved user accounts in my password manager, they seem to try to autofill that field (I suspect because of an html flag inviting this behavior?) at all costs, even though it's not the page username/password field. I'd speculate this file context menu field needs attribute 'type="text"' or something similar to make it behave better.

[error311]

Awesome glad you like FileRise and appreciate your contribution to the project. Happy to hear you thinking of daily FileRise. I have been and built FileRise because I couldn't find one that did and looked like I wanted lol. Any ideas or request let me know.

@SimonMischenkoHawk If you could open a new issue that would be great so we can track it.

[error311]

@SimonMischenkoHawk

I made few more changes to DockerFile and start.sh to further increase security.
2792c05

• Hardened Dockerfile permissions: all code files owned by root:www-data (dirs 755, files 644), only uploads/, users/ and metadata/ are writable by www-data (775)
• .dockerignore entry to exclude the .github directory from build context
• start.sh:
  • Creates and secures metadata/log for Apache logs
  • Dynamically creates and sets permissions on uploads, users, and metadata directories at startup
• Apache VirtualHost updated to redirect ErrorLog and CustomLog into /var/www/metadata/log
• docker: remove symlink add alias for uploads folder