|
Hi Mantas, I currently have the following flow:
I can’t explain why the /run/user/1001 is owned by root after
user-runtime-dir@1001.service successfully exited. I added some personal print in systemd code to ensure that the mount command returned success (r=0). Although, the mount was successful the command “mount”
didn’t list it. In the list of mounts starting with /run I could only find these entries: Dec 12 16:19:35 host mount[14500]: tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) Dec 12 16:19:35 host mount[14500]: tmpfs on /run/credentials type tmpfs (ro,nosuid,nodev,noexec,mode=755) Dec 12 16:19:35 host mount[14500]: tmpfs on /run/systemd/incoming type tmpfs (ro,nosuid,nodev,mode=755) If I do a chown of the directory in
user@1001.service then it works root@host:/run/user# ls -la 1001 drwx------ 3 ida root 80 Dec 12 16:19 . drwxr-xr-x 3 root root 60 Dec 12 16:19 .. srw-rw-rw- 1 ida ssh-user 0 Dec 12 16:19 bus drwxr-xr-x 5 ida ssh-user 140 Dec 12 16:19 systemd The ”mount” command don’t list /run/user/1001 for the successful case either. Best regards, Christopher Wong From:
Mantas Mikulėnas <grawity@xxxxxxxxx> On Mon, Dec 11, 2023, 17:28 Christopher Wong <Christopher.Wong@xxxxxxxx> wrote:
No, it should be owned by UID 1001 (though still mode 0700).
Which user started the .service is usually not important, all services get a "fresh" environment that's fully described by the unit file. So even if you did 'systemctl start' as root, the unit has User=%i so the instance parameter tells it which UID to run as, so will be running as UID 1001. Likewise user-runtime-dir@1001 will get the UID for
the mount from its instance name (you can see that the "Mounting tmpfs" message has the correct information).
So far, it sounds like the directory is being created *by something else* before user-runtime-dir@ is even invoked. Try adding the same "-/bin/ls -lad /run/user/%i" as both ExecStartPre and ExecStartPost of user-runtime-dir@ (and maybe even a findmnt). If the directory already exists during ExecStartPre, start looking for
other services or cronjobs, or tmpfiles.d configs, or 'su' invocations, which may cause it to be created. There might also be something that chowns it to root *after* it was created correctly. If you actually see the tmpfs mount in 'findmnt' or in 'mount', but it's owned by root despite having uid=1001 in its
mount options, something has chowned it...or your tmpfs feature is broken. If you don't see it in findmnt at all, even after user-runtime-dir has succeeded – either the mount failed quietly, or... something (like systemd itself) has quietly unmounted it.
|
|
Hi Mantas, I currently have the following flow:
I can’t explain why the /run/user/1001 is owned by root after
user-runtime-dir@1001.service successfully exited. I added some personal print in systemd code to ensure that the mount command returned success (r=0). Although, the mount was successful the command “mount”
didn’t list it. In the list of mounts starting with /run I could only find these entries: Dec 12 16:19:35 host mount[14500]: tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) Dec 12 16:19:35 host mount[14500]: tmpfs on /run/credentials type tmpfs (ro,nosuid,nodev,noexec,mode=755) Dec 12 16:19:35 host mount[14500]: tmpfs on /run/systemd/incoming type tmpfs (ro,nosuid,nodev,mode=755) If I do a chown of the directory in
user@1001.service then it works root@host:/run/user# ls -la 1001 drwx------ 3 ida root 80 Dec 12 16:19 . drwxr-xr-x 3 root root 60 Dec 12 16:19 .. srw-rw-rw- 1 ida ssh-user 0 Dec 12 16:19 bus drwxr-xr-x 5 ida ssh-user 140 Dec 12 16:19 systemd The ”mount” command don’t list /run/user/1001 for the successful case either. Best regards, Christopher Wong |
