So I logged into one user account su username
No, you did not.
You are not logging in. You are augmenting the privileges of your existing login session with su username.
systemctl with the --user option locates your per-user Desktop Bus, managed by you per-user Desktop Bus dæmon, and via that bus communicates with your per-user instance of systemd that manages your per-user servics.
su is not a login mechanism. It works within an existing interactive login session. In that session, your processes have environment variables that tell them where your per-user runtime directory is (XDG_RUNTIME_DIR), where the per-user Desktop Bus is (DBUS_SESSION_BUS_ADDRESS), and indeed other things like where your X server is (DISPLAY).
In particular, DBUS_SESSION_BUS_ADDRESS can implicitly reference XDG_RUNTIME_DIR or can explicitly name the same path. That path will generally be something like /run/user/1001/bus for the Desktop Bus broker's access socket (presuming that your user ID is 1001, for example).
These variables are not changed by su. There's been a whole back and forth for many years over this, including the behaviours of other similar commands such as pkexec.
The consequence of this is that if you su to a second user in your login session, running systemctl as that second user tries to connect to a Desktop Bus broker access socket located in a directory private to the first user. User 1002 (to pick a user ID for your second user for the sake of example) cannot access /run/user/1001 or anything within it, and even if xe had read+execute access to that directory xe cannot access /run/user/1001/bus because that only grants access to user 1001 also.
Of course, this is not the right Desktop Bus broker to be talking to in the first place. You want to talk to the second user's Desktop Bus broker, and through it to the second user's per-user instance of systemd.
The simple solution is as part of the su to set those environment variables to the ones appropriate for the second user account, pointing to the second user's Desktop Bus:
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1002/bus su username -c 'systemctl --user'
I of course in such circumstances use a handy tool for setting this, userenv, which enables me not to have to type that bus address longhand:
su username -c 'userenv --set-dbus systemctl --user'
Further reading
Best Answer
Use
sudo -s -H -u git-auto-deploy.sudoby itself does not change the value ofHOME, but does so when-His used. This is why you're getting that "Permission denied" error. The user can't accessroot's home directory (and shouldn't be able to either).The
-soption makessudostart whatever shell is configured as the login shell for the specified user (i.e. no need to explicitly run/bin/bash).