docker
docker copied to clipboard
Allow the entry point script to execute the app hooks as script owner
The entry point is a useful feature for added customization for NextCloud owners. Unfortunately, I still need to execute mine manually as some require root level permissions to actually execute. It would be great to allow the scripts to execute as the same user that owns it, on the condition that it probably can be only read, written, or executed by the user only. I am aware that this has security implications, but I believe it should be feasible to implement in a secure manner, maybe even adding an environment variable that must be set to 1 to even allow the scripts to execute as root in the first place?
Also having this problem. Here is a specific example of the problem.
I use watchtower to update my instance automatically, whenever that happens, smbclient needs to be reinstalled. I created a script called smbclient.sh and placed it into the before-starting hook folder. Nextcloud sees this and tries to execute, but every command in the script returns a 13: Permission denied error.
The script is as follows:
#!/bin/sh
apt update
apt install smbclient libsmbclient-dev -y
pecl install smbclient
docker-php-ext-enable smbclient
I did some digging. Apparently this how it is supposed to work.
The workaround involves adding an entrypoint option to your docker-compose file. Here is an example:
entrypoint: ["/bin/bash", "-c" , "apt update && apt install smbclient libsmbclient-dev -y && pecl install smbclient && docker-php-ext-enable smbclient && /entrypoint.sh apache2-foreground"]
I don't have that option since my container lives on TrueNAS, and there doesn't exist an option to do that.
I did some digging. Apparently this how it is supposed to work.
The workaround involves adding an entrypoint option to your docker-compose file. Here is an example:
entrypoint: ["/bin/bash", "-c" , "apt update && apt install smbclient libsmbclient-dev -y && pecl install smbclient && docker-php-ext-enable smbclient && /entrypoint.sh apache2-foreground"]
This solution works but the Autoconfiguration via hook folder lost its utility.
Anyone have a idea about how to run this scripts as root?
This solution works but the Autoconfiguration via hook folder lost its utility.
https://github.com/nextcloud/docker/pull/1964#issuecomment-1663287070
For auto-configuring Nextcloud (i.e. via occ
) they work as designed because they run under the appropriate uid.
I understand the idea of wanting to use them for other custom changes, but there are at least other ways of doing those still (e.g. entrypoint overrides, Dockerfile changes/builds). The Dockerfile method is probably the most appropriate, since root -level changes are generally changes to the underlying image rather than config changes for Nextcloud (and also are the most likely to break during underlying image changes such as OS base upgrades).
There was some discussion about different run_as
user support for hooks in prior PRs (e.g. see #1260).
This solution works but the Autoconfiguration via hook folder lost its utility.
For auto-configuring Nextcloud (i.e. via
occ
) they work as designed because they run under the appropriate uid.I understand the idea of wanting to use them for other custom changes, but there are at least other ways of doing those still (e.g. entrypoint overrides, Dockerfile changes/builds). The Dockerfile method is probably the most appropriate, since root -level changes are generally changes to the underlying image rather than config changes for Nextcloud (and also are the most likely to break during underlying image changes such as OS base upgrades).
There was some discussion about different
run_as
user support for hooks in prior PRs (e.g. see #1260).
Unfortunately, not really much of an option if you run TrueNAS as those docker files are auto-generated. I can mount a host path to the entry points folder and add something to before-starting, but that's about it.
Fair enough (I'm not using TrueNAS). It at least looks like TrueNAS should still permit entrypoint command overrides from a cursory documentation search. Also I'd think you could point at a private/alternative image if you build it (Dockerfile) and upload it to an accessible image repo.
Other option is to revive some of the un-merged run_as
functionality (as mentioned in #1260) for hooks and propose an implementation adjustment in a PR that supports both the current mode + a root/equivalent override.