How to move systemd user units config directory

I think the problem is that systemd insists on creating symlinks in ${HOME}/.config/systemd/user when enabling units and if that directory isnt accessible (common with NFS homes / restrictive permissions etc) then you are stuck.

You can override where systemd looks for user units by creating a drop-in config:

sudo mkdir -p /etc/systemd/system.conf.d/

Then create a file /etc/systemd/system.conf.d/user-units-path.conf with:

[Manager] 
DefaultUserUnitPath=/var/lib/systemd/users/%U/units:/etc/systemd/user

The %U gets replaced with the username. I chose /var/lib/systemd/users/ because it's a sensible location that doesn't conflict with other stuff but you can pick something else.

After creating this file, reload systemd:

sudo systemctl daemon-reload

Then create the necessary directories for each user and set permissions:

sudo mkdir -p /var/lib/systemd/users/username/units
sudo chown username:username /var/lib/systemd/users/username -R

Now your users can enable and start units using systemctl --user enable whatever.service and it'll create the symlinks in the new location instead of failing to access ~/.config/systemd/user.

I've been running this setup for months without any issues. Hope this helps!

The path is really $XDGCONFIGHOME/systemd/user.

However, systemd --user is run in a separate "service" environment (which is also probably the reason it can't access the user's HOME in your weird setup?), therefore XDGCONFIGHOME has to be set in the environment of that service – user@.service – and not merely in the user's "shell" environment.

In other words, ~/.profile or ~/.bashrc won't do. You have to systemctl edit user@.service instead and set XDGCONFIGHOME there.

Keep in mind that it'll also affect all user programs run from 'systemd --user', i.e. their config directories will also move to the new location. It might be possible to undo this through DefaultEnvironment= or ManagerEnvironment= in systemd-user.conf(5).

I would ask why, as systemd defaults systemwide and uses symlinks. As /etc/systemd/ can break your O/S if you mess around with it, I would recommend assuming its a newer kernal version the following:

1. If required, change the user level symlinks ONLY, leave system wide as default. Personally, I would skip and goto number 2 below for systemwide changes. If its user based, then probably inadvisable.

2. User systemd override process, not direct file manipulation when changing, adding, etc on systemd config files via sudo systemctl edit mydaemond and use the override feature. To illustrate the edit process, in the VI console of the unit file, user link key like WantedBy= with a line below WantedBy=multi-user.target. This will use the override file to implement the changes. Reload damons with sudo systemctl daemon-reload (reloads the daemon's unit file with the overrides).

   1. IF your server is running on a low spec shape (e.g. AWS t2.micro), give unit files a few seconds to reload.

   Then check it with sudo systemctl status mydaemond.