Grant postgres user access to PATH?

I’m currently configuring backups for a postgresql instance by setting the archive_command among other things. At this moment execution of this command (by the postgres user) fails as it does not have access to the most basic CLI tooling normally accessible through the PATH.

Configuring another postgres user through the users configuration seems to be messing with folder permissions.

What is the most straightforward way to grant the postgres user access to these tools (sh, borg, etc.)?

Edit: currently running export PATH=/run/current-system/sw/bin:$PATH; ... as part of the postgres command seems to be fine. I’ll take that :slight_smile:

1 Like

I think you can add to the systemd.services.<name>.path option of the postgres service.

2 Likes

Could you reference the packages directly in your script, without PATH?

e.g. “${pkgs.borgbackup}/bin/borg --options”

2 Likes

I imagine you’re defining the archive_command and postgres config with Nix?

What does your archive_command look like? Is it just a shell invocation using those tools, or does it invoke a separate script that’s failing?

If it’s the former, you can probably do what coreyoconnor suggested above and/or use inline dependency references as Lyndeno did. If it’s a separate nontrivial script, it may be better to package the script and use the package there (the inline package reference approach would work for that as well).

1 Like

Currently the postgres config happens through Nix, though the setup of the archive_command happened through postgres itself, invoking an external script, failing even before the invocation.

Upon further consideration I might as well have used services.postgresql.settings option to configure the archive_command instead, at which point this would probably be a non-issue, and if not I suspect @Lyndeno’s solution would work!

Currently waiting for a DB import to finish. Let me play around some more after that’s complete!