Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Mantas,

I finally found out what was causing this mount issue. We have a global 
sandboxing configuration for all services, that implies PrivateNetwork=yes. 
According to manual this will imply PrivateMounts=yes. So, I added a drop-in 
configuration to 
user-runtime-dir@.service.d<mailto:user-runtime-dir@.service.d> which defines 
PrivateMounts=no. Now it works! 

Thank you very much for your support!

Best regards,
Christopher Wong


From: systemd-devel  on behalf of 
Christopher Wong 
Date: Wednesday, 13 December 2023 at 11:32
To: Mantas Mikulėnas 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
Hi Mantas,

I ran your suggestion and here is the result:

root@host:/run/user# ls -la
drwxr-xr-x2 root root40 Dec 13 11:24 .
drwxr-xr-x   99 root root  2160 Dec 13 11:00 ..
root@host:/run/user# /usr/lib/systemd/systemd-user-runtime-dir start 1001
root@host:/run/user# ls -la
drwxr-xr-x3 root root60 Dec 13 11:25 .
drwxr-xr-x   99 root root  2160 Dec 13 11:00 ..
drwx--2 ida  ssh-user40 Dec 13 11:25 1001
root@host:/run/user# mount | grep /run
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/user/1001 type tmpfs 
(rw,nosuid,nodev,relatime,size=97096k,nr_inodes=24274,mode=700,uid=1001,gid=118)

This seems to be correct, and I could see /run/user/1001 listed using “mount”.

Thank you for your explaination! We have probably be running with a uncomplete 
setup of the mount before.

Best regards,
Christopher Wong


From: Mantas Mikulėnas 
Date: Wednesday, 13 December 2023 at 10:33
To: Christopher Wong 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Wed, Dec 13, 2023 at 10:36 AM Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

I tried with StopWhenUnneeded=no in 
user-runtime-dir@.service<mailto:user-runtime-dir@.service>, then when 
user@1001.service<mailto:user@1001.service> fails the status of 
user-runtime-dir@.service<mailto:user-runtime-dir@.service> is active. At this 
state the directory /run/user/1001 is created, it is empty, owned by root. 
Running the mount command doesn’t show /run/user/1001.

Run the "/usr/lib/systemd/systemd-user-runtime-dir start 1001" manually and 
check whether the mounted filesystem is there afterwards.

If it's still not there, then run "mount -t tmpfs -o uid=1001,mode=0700 none 
/run/user/1001" and then check whether it stays mounted.



I have mentioned it before, but I want to point out that if I put 
“ExecStartPre=+chown %i /run/user/%i” in user@.service<mailto:user@.service> 
then the user@1001.service<mailto:user@1001.service> can be started manually. 
The mount command doesn’t show /run/user/1001 either, but since the service is 
started the path contains bus socket and systemd directory with content, which 
are the things I am after.

The main issue here is that /run/user/1001 is owned by root after 
user-runtime-dir@.service<mailto:user-runtime-dir@.service> has been exited 
successfully.

No, that's only a symptom of the main issue.

The current design that systemd implements is to have a user-specific tmpfs 
mounted at that location (for quota purposes), and so the underlying mountpoint 
is deliberately created as owned by root – its ownership is not changed because 
it's supposed to have a new filesystem mounted on top (which would make the 
mountpoint hidden and its ownership moot).

If you specifically want to *not* have an additional tmpfs there, then you can 
continue using the manual "ExecStartPre=chown" (or in fact you could replace 
the entire user-runtime-dir@ with a simpler one that only mkdirs and chowns), 
but in that case you shouldn't be saying that it's a systemd issue that it 
doesn't chown something that it was never meant to chown to begin with.


Best regards,
Christopher Wong


From: Mantas Mikulėnas mailto:graw...@gmail.com>>
Date: Wednesday, 13 December 2023 at 08:08
To: Christopher Wong 
mailto:christopher.w...@axis.com>>
Cc: Systemd 
mailto:systemd-devel@lists.freedesktop.org>>
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Tue, Dec 12, 2023 at 6:15 PM Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

After user@1001.service<mailto:user@1001.service> failed, it trigger the 
stopping process and become inactive.

Ah yeah, that makes sense, user-runtime-dir@ has StopWhenUnneeded=yes – so of 
course after user@1001 crashes you're not going to see anything mounted anymore.

Could you try temporarily removing that option / setting it to 'no', just to 
see what changes?



○ user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> - User 
Runtime Directory /run/user/1001

 Loaded: loaded 
(/etc/systemd/system/user-runtime-

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Mantas,

I ran your suggestion and here is the result:

root@host:/run/user# ls -la
drwxr-xr-x2 root root40 Dec 13 11:24 .
drwxr-xr-x   99 root root  2160 Dec 13 11:00 ..
root@host:/run/user# /usr/lib/systemd/systemd-user-runtime-dir start 1001
root@host:/run/user# ls -la
drwxr-xr-x3 root root60 Dec 13 11:25 .
drwxr-xr-x   99 root root  2160 Dec 13 11:00 ..
drwx--2 ida  ssh-user40 Dec 13 11:25 1001
root@host:/run/user# mount | grep /run
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/user/1001 type tmpfs 
(rw,nosuid,nodev,relatime,size=97096k,nr_inodes=24274,mode=700,uid=1001,gid=118)

This seems to be correct, and I could see /run/user/1001 listed using “mount”.

Thank you for your explaination! We have probably be running with a uncomplete 
setup of the mount before.

Best regards,
Christopher Wong


From: Mantas Mikulėnas 
Date: Wednesday, 13 December 2023 at 10:33
To: Christopher Wong 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Wed, Dec 13, 2023 at 10:36 AM Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

I tried with StopWhenUnneeded=no in 
user-runtime-dir@.service<mailto:user-runtime-dir@.service>, then when 
user@1001.service<mailto:user@1001.service> fails the status of 
user-runtime-dir@.service<mailto:user-runtime-dir@.service> is active. At this 
state the directory /run/user/1001 is created, it is empty, owned by root. 
Running the mount command doesn’t show /run/user/1001.

Run the "/usr/lib/systemd/systemd-user-runtime-dir start 1001" manually and 
check whether the mounted filesystem is there afterwards.

If it's still not there, then run "mount -t tmpfs -o uid=1001,mode=0700 none 
/run/user/1001" and then check whether it stays mounted.



I have mentioned it before, but I want to point out that if I put 
“ExecStartPre=+chown %i /run/user/%i” in user@.service<mailto:user@.service> 
then the user@1001.service<mailto:user@1001.service> can be started manually. 
The mount command doesn’t show /run/user/1001 either, but since the service is 
started the path contains bus socket and systemd directory with content, which 
are the things I am after.

The main issue here is that /run/user/1001 is owned by root after 
user-runtime-dir@.service<mailto:user-runtime-dir@.service> has been exited 
successfully.

No, that's only a symptom of the main issue.

The current design that systemd implements is to have a user-specific tmpfs 
mounted at that location (for quota purposes), and so the underlying mountpoint 
is deliberately created as owned by root – its ownership is not changed because 
it's supposed to have a new filesystem mounted on top (which would make the 
mountpoint hidden and its ownership moot).

If you specifically want to *not* have an additional tmpfs there, then you can 
continue using the manual "ExecStartPre=chown" (or in fact you could replace 
the entire user-runtime-dir@ with a simpler one that only mkdirs and chowns), 
but in that case you shouldn't be saying that it's a systemd issue that it 
doesn't chown something that it was never meant to chown to begin with.


Best regards,
Christopher Wong


From: Mantas Mikulėnas mailto:graw...@gmail.com>>
Date: Wednesday, 13 December 2023 at 08:08
To: Christopher Wong 
mailto:christopher.w...@axis.com>>
Cc: Systemd 
mailto:systemd-devel@lists.freedesktop.org>>
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Tue, Dec 12, 2023 at 6:15 PM Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

After user@1001.service<mailto:user@1001.service> failed, it trigger the 
stopping process and become inactive.

Ah yeah, that makes sense, user-runtime-dir@ has StopWhenUnneeded=yes – so of 
course after user@1001 crashes you're not going to see anything mounted anymore.

Could you try temporarily removing that option / setting it to 'no', just to 
see what changes?



○ user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> - User 
Runtime Directory /run/user/1001

 Loaded: loaded 
(/etc/systemd/system/user-runtime-dir@.service<mailto:/etc/systemd/system/user-runtime-dir@.service>;
 static)

Drop-In: /usr/lib/systemd/system/service.d

 └─10-axis.conf, 20-axis-sandbox.conf

 Active: inactive (dead) since Tue 2023-12-12 16:33:35 CET; 36min ago

   Duration: 315ms

   Docs: man:user@.service(5)

Process: 16325 ExecStartPre=ls -la /run/user (code=exited, status=0/SUCCESS)

Process: 16327 ExecStartPre=mount (code=exited, status=0/SUCCESS)

Process: 16329 ExecStart=/usr/lib/systemd/systemd-user-runtime-dir start 
1001 (code=exited, status=0/SUCCESS)

Process: 16334 ExecStartPost=sleep 5 (code=exited, status=0/SUCCESS)

Process: 16347 

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Mantas Mikulėnas]

On Wed, Dec 13, 2023 at 10:36 AM Christopher Wong 
wrote:

> Hi Mantas,
>
>
>
> I tried with StopWhenUnneeded=no in user-runtime-dir@.service, then when
> user@1001.service fails the status of user-runtime-dir@.service is
> active. At this state the directory /run/user/1001 is created, it is empty,
> owned by root. Running the mount command doesn’t show /run/user/1001.
>

Run the "/usr/lib/systemd/systemd-user-runtime-dir start 1001" manually and
check whether the mounted filesystem is there afterwards.

If it's still not there, then run "mount -t tmpfs -o uid=1001,mode=0700
none /run/user/1001" and then check whether it stays mounted.


>
>
> I have mentioned it before, but I want to point out that if I put 
> “ExecStartPre=+chown
> %i /run/user/%i” in user@.service then the user@1001.service can be
> started manually. The mount command doesn’t show /run/user/1001 either, but
> since the service is started the path contains bus socket and systemd
> directory with content, which are the things I am after.
>
>
>
> The main issue here is that /run/user/1001 is owned by root after
> user-runtime-dir@.service has been exited successfully.
>

No, that's only a symptom of the main issue.

The current design that systemd implements is to have a user-specific tmpfs
mounted at that location (for quota purposes), and so the underlying
mountpoint is deliberately created as owned by root – its ownership is not
changed because it's supposed to have a new filesystem mounted on top
(which would make the mountpoint hidden and its ownership moot).

If you specifically want to *not* have an additional tmpfs there, then you
can continue using the manual "ExecStartPre=chown" (or in fact you could
replace the entire user-runtime-dir@ with a simpler one that only mkdirs
and chowns), but in that case you shouldn't be saying that it's a systemd
issue that it doesn't chown something that it was never meant to chown to
begin with.


>
>
> Best regards,
>
> Christopher Wong
>
>
>
>
>
> *From: *Mantas Mikulėnas 
> *Date: *Wednesday, 13 December 2023 at 08:08
> *To: *Christopher Wong 
> *Cc: *Systemd 
> *Subject: *Re: [systemd-devel] Manual start of user@.service failed
> with permission denied
>
> On Tue, Dec 12, 2023 at 6:15 PM Christopher Wong <
> christopher.w...@axis.com> wrote:
>
> Hi Mantas,
>
>
>
> After user@1001.service failed, it trigger the stopping process and
> become inactive.
>
>
>
> Ah yeah, that makes sense, user-runtime-dir@ has StopWhenUnneeded=yes –
> so of course after user@1001 crashes you're not going to see anything
> mounted anymore.
>
>
>
> Could you try temporarily removing that option / setting it to 'no', just
> to see what changes?
>
>
>
>
>
> ○ user-runtime-dir@1001.service - User Runtime Directory /run/user/1001
>
>  Loaded: loaded (/etc/systemd/system/user-runtime-dir@.service;
> static)
>
> Drop-In: /usr/lib/systemd/system/service.d
>
>  └─10-axis.conf, 20-axis-sandbox.conf
>
>  Active: inactive (dead) since Tue 2023-12-12 16:33:35 CET; 36min ago
>
>Duration: 315ms
>
>Docs: man:user@.service(5)
>
> Process: 16325 ExecStartPre=ls -la /run/user (code=exited,
> status=0/SUCCESS)
>
> Process: 16327 ExecStartPre=mount (code=exited, status=0/SUCCESS)
>
> Process: 16329 ExecStart=/usr/lib/systemd/systemd-user-runtime-dir
> start 1001 (code=exited, status=0/SUCCESS)
>
> Process: 16334 ExecStartPost=sleep 5 (code=exited, status=0/SUCCESS)
>
> Process: 16347 ExecStartPost=ls -la /run/user/1001 (code=exited,
> status=0/SUCCESS)
>
> Process: 16351 ExecStartPost=mount (code=exited, status=0/SUCCESS)
>
> Process: 16361 ExecStop=/usr/lib/systemd/systemd-user-runtime-dir
> stop 1001 (code=exited, status=0/SUCCESS)
>
>Main PID: 16329 (code=exited, status=0/SUCCESS)
>
>     CPU: 48ms
>
>
>
> /etc/fstab don’t include anything on /run/user/1001 and there is no mount
> unit for run-user-1001.mount either.
>
>
>
> Best regards,
>
> Christopher Wong
>
>
>
>
>
> *From: *Mantas Mikulėnas 
> *Date: *Tuesday, 12 December 2023 at 17:05
> *To: *Christopher Wong 
> *Cc: *Systemd 
> *Subject: *Re: [systemd-devel] Manual start of user@.service failed
> with permission denied
>
> That sounds like it's getting immediately unmounted (or maybe not being
> mounted at all despite the program doing so).
>
>
>
> Does the user-runtime-dir service continue to show as "active" after this,
> or does it return to "inactive"?
>
>
>
> Does your /etc/fstab have any mentions of /run/user/1001? Or more
> generally, ar

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Mantas,

I tried with StopWhenUnneeded=no in 
user-runtime-dir@.service<mailto:user-runtime-dir@.service>, then when 
user@1001.service<mailto:user@1001.service> fails the status of 
user-runtime-dir@.service<mailto:user-runtime-dir@.service> is active. At this 
state the directory /run/user/1001 is created, it is empty, owned by root. 
Running the mount command doesn’t show /run/user/1001.

● user-runtime-dir@1001.service - User Runtime Directory /run/user/1001
 Loaded: loaded (/etc/systemd/system/user-runtime-dir@.service; static)
Drop-In: /usr/lib/systemd/system/service.d
 └─10-axis.conf, 20-axis-sandbox.conf
 Active: active (exited) since Wed 2023-12-13 09:16:57 CET; 33s ago
   Docs: man:user@.service(5)
Process: 133303 ExecStartPre=ls -la /run/user (code=exited, 
status=0/SUCCESS)
Process: 133305 ExecStartPre=mount (code=exited, status=0/SUCCESS)
Process: 133307 ExecStart=/usr/lib/systemd/systemd-user-runtime-dir start 
1001 (code=exited, status=0/SUCCESS)
Process: 133309 ExecStartPost=ls -la /run/user/1001 (code=exited, 
status=0/SUCCESS)
Process: 133310 ExecStartPost=mount (code=exited, status=0/SUCCESS)
   Main PID: 133307 (code=exited, status=0/SUCCESS)
CPU: 209ms


I have mentioned it before, but I want to point out that if I put 
“ExecStartPre=+chown %i /run/user/%i” in user@.service<mailto:user@.service> 
then the user@1001.service<mailto:user@1001.service> can be started manually. 
The mount command doesn’t show /run/user/1001 either, but since the service is 
started the path contains bus socket and systemd directory with content, which 
are the things I am after.

The main issue here is that /run/user/1001 is owned by root after 
user-runtime-dir@.service<mailto:user-runtime-dir@.service> has been exited 
successfully.

Best regards,
Christopher Wong


From: Mantas Mikulėnas 
Date: Wednesday, 13 December 2023 at 08:08
To: Christopher Wong 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Tue, Dec 12, 2023 at 6:15 PM Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

After user@1001.service<mailto:user@1001.service> failed, it trigger the 
stopping process and become inactive.

Ah yeah, that makes sense, user-runtime-dir@ has StopWhenUnneeded=yes – so of 
course after user@1001 crashes you're not going to see anything mounted anymore.

Could you try temporarily removing that option / setting it to 'no', just to 
see what changes?



○ user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> - User 
Runtime Directory /run/user/1001

 Loaded: loaded 
(/etc/systemd/system/user-runtime-dir@.service<mailto:/etc/systemd/system/user-runtime-dir@.service>;
 static)

Drop-In: /usr/lib/systemd/system/service.d

 └─10-axis.conf, 20-axis-sandbox.conf

 Active: inactive (dead) since Tue 2023-12-12 16:33:35 CET; 36min ago

   Duration: 315ms

   Docs: man:user@.service(5)

Process: 16325 ExecStartPre=ls -la /run/user (code=exited, status=0/SUCCESS)

Process: 16327 ExecStartPre=mount (code=exited, status=0/SUCCESS)

Process: 16329 ExecStart=/usr/lib/systemd/systemd-user-runtime-dir start 
1001 (code=exited, status=0/SUCCESS)

Process: 16334 ExecStartPost=sleep 5 (code=exited, status=0/SUCCESS)

Process: 16347 ExecStartPost=ls -la /run/user/1001 (code=exited, 
status=0/SUCCESS)

Process: 16351 ExecStartPost=mount (code=exited, status=0/SUCCESS)

Process: 16361 ExecStop=/usr/lib/systemd/systemd-user-runtime-dir stop 1001 
(code=exited, status=0/SUCCESS)

   Main PID: 16329 (code=exited, status=0/SUCCESS)

CPU: 48ms

/etc/fstab don’t include anything on /run/user/1001 and there is no mount unit 
for run-user-1001.mount either.

Best regards,
Christopher Wong


From: Mantas Mikulėnas mailto:graw...@gmail.com>>
Date: Tuesday, 12 December 2023 at 17:05
To: Christopher Wong 
mailto:christopher.w...@axis.com>>
Cc: Systemd 
mailto:systemd-devel@lists.freedesktop.org>>
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
That sounds like it's getting immediately unmounted (or maybe not being mounted 
at all despite the program doing so).

Does the user-runtime-dir service continue to show as "active" after this, or 
does it return to "inactive"?

Does your /etc/fstab have any mentions of /run/user/1001? Or more generally, 
are there any run-user-1001.mount units? (If you 'systemctl status' this unit, 
does the status include a source path?)

On Tue, Dec 12, 2023, 17:34 Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

I currently have the following flow:


  1.  No /run/user/1001 directory
  2.  systemctl start user@1001.service<mailto:user@1001.service>
  3.  systemd start 
user-runtime-dir@1001.service<mailto:user-runtime-dir@1

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Mantas Mikulėnas]

On Tue, Dec 12, 2023 at 6:15 PM Christopher Wong 
wrote:

> Hi Mantas,
>
>
>
> After user@1001.service failed, it trigger the stopping process and
> become inactive.
>

Ah yeah, that makes sense, user-runtime-dir@ has StopWhenUnneeded=yes – so
of course after user@1001 crashes you're not going to see anything mounted
anymore.

Could you try temporarily removing that option / setting it to 'no', just
to see what changes?


>
>
> ○ user-runtime-dir@1001.service - User Runtime Directory /run/user/1001
>
>  Loaded: loaded (/etc/systemd/system/user-runtime-dir@.service;
> static)
>
> Drop-In: /usr/lib/systemd/system/service.d
>
>  └─10-axis.conf, 20-axis-sandbox.conf
>
>  Active: inactive (dead) since Tue 2023-12-12 16:33:35 CET; 36min ago
>
>Duration: 315ms
>
>Docs: man:user@.service(5)
>
> Process: 16325 ExecStartPre=ls -la /run/user (code=exited,
> status=0/SUCCESS)
>
> Process: 16327 ExecStartPre=mount (code=exited, status=0/SUCCESS)
>
> Process: 16329 ExecStart=/usr/lib/systemd/systemd-user-runtime-dir
> start 1001 (code=exited, status=0/SUCCESS)
>
> Process: 16334 ExecStartPost=sleep 5 (code=exited, status=0/SUCCESS)
>
> Process: 16347 ExecStartPost=ls -la /run/user/1001 (code=exited,
> status=0/SUCCESS)
>
> Process: 16351 ExecStartPost=mount (code=exited, status=0/SUCCESS)
>
> Process: 16361 ExecStop=/usr/lib/systemd/systemd-user-runtime-dir
> stop 1001 (code=exited, status=0/SUCCESS)
>
>Main PID: 16329 (code=exited, status=0/SUCCESS)
>
> CPU: 48ms
>
>
>
> /etc/fstab don’t include anything on /run/user/1001 and there is no mount
> unit for run-user-1001.mount either.
>
>
>
> Best regards,
>
> Christopher Wong
>
>
>
>
>
> *From: *Mantas Mikulėnas 
> *Date: *Tuesday, 12 December 2023 at 17:05
> *To: *Christopher Wong 
> *Cc: *Systemd 
> *Subject: *Re: [systemd-devel] Manual start of user@.service failed
> with permission denied
>
> That sounds like it's getting immediately unmounted (or maybe not being
> mounted at all despite the program doing so).
>
>
>
> Does the user-runtime-dir service continue to show as "active" after this,
> or does it return to "inactive"?
>
>
>
> Does your /etc/fstab have any mentions of /run/user/1001? Or more
> generally, are there any run-user-1001.mount units? (If you 'systemctl
> status' this unit, does the status include a source path?)
>
>
>
> On Tue, Dec 12, 2023, 17:34 Christopher Wong 
> wrote:
>
> Hi Mantas,
>
>
>
> I currently have the following flow:
>
>
>
>1. No /run/user/1001 directory
>2. systemctl start user@1001.service
>3. systemd start user-runtime-dir@1001.service which ends successfully.
>4. The directory /run/user/1001 exists now, but is empty, owned by
>root with mode 0700
>5. I don’t have findmnt on my system, so I used mount, but
>/run/user/1001 is not listed.
>6. systemd start user@1001.service which fails due to permission
>denied.
>
>
>
> 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  root80 Dec 12 16:19 .
>
> drwxr-xr-x3 root root    60 Dec 12 16:19 ..
>
> srw-rw-rw-1 ida  ssh-user     0 Dec 12 16:19 bus
>
> drwxr-xr-x5 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 
> *Date: *Monday, 11 December 2023 at 17:56
> *To: *Christopher Wong 
> *Cc: *Systemd 
> *Subject: *Re: [systemd-devel] Manual start of user@.service failed
> with permission denied
>
> On Mon, Dec 11, 2023, 17:28 Christopher Wong 
> wrote:
>
> Hi Mantas,
>
>
>
> I have a

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Mantas,

After user@1001.service<mailto:user@1001.service> failed, it trigger the 
stopping process and become inactive.


○ user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> - User 
Runtime Directory /run/user/1001

 Loaded: loaded 
(/etc/systemd/system/user-runtime-dir@.service<mailto:/etc/systemd/system/user-runtime-dir@.service>;
 static)

Drop-In: /usr/lib/systemd/system/service.d

 └─10-axis.conf, 20-axis-sandbox.conf

 Active: inactive (dead) since Tue 2023-12-12 16:33:35 CET; 36min ago

   Duration: 315ms

   Docs: man:user@.service(5)

Process: 16325 ExecStartPre=ls -la /run/user (code=exited, status=0/SUCCESS)

Process: 16327 ExecStartPre=mount (code=exited, status=0/SUCCESS)

Process: 16329 ExecStart=/usr/lib/systemd/systemd-user-runtime-dir start 
1001 (code=exited, status=0/SUCCESS)

Process: 16334 ExecStartPost=sleep 5 (code=exited, status=0/SUCCESS)

Process: 16347 ExecStartPost=ls -la /run/user/1001 (code=exited, 
status=0/SUCCESS)

Process: 16351 ExecStartPost=mount (code=exited, status=0/SUCCESS)

Process: 16361 ExecStop=/usr/lib/systemd/systemd-user-runtime-dir stop 1001 
(code=exited, status=0/SUCCESS)

   Main PID: 16329 (code=exited, status=0/SUCCESS)

CPU: 48ms

/etc/fstab don’t include anything on /run/user/1001 and there is no mount unit 
for run-user-1001.mount either.

Best regards,
Christopher Wong


From: Mantas Mikulėnas 
Date: Tuesday, 12 December 2023 at 17:05
To: Christopher Wong 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
That sounds like it's getting immediately unmounted (or maybe not being mounted 
at all despite the program doing so).

Does the user-runtime-dir service continue to show as "active" after this, or 
does it return to "inactive"?

Does your /etc/fstab have any mentions of /run/user/1001? Or more generally, 
are there any run-user-1001.mount units? (If you 'systemctl status' this unit, 
does the status include a source path?)

On Tue, Dec 12, 2023, 17:34 Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

I currently have the following flow:


  1.  No /run/user/1001 directory
  2.  systemctl start user@1001.service<mailto:user@1001.service>
  3.  systemd start 
user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> which ends 
successfully.
  4.  The directory /run/user/1001 exists now, but is empty, owned by root with 
mode 0700
  5.  I don’t have findmnt on my system, so I used mount, but /run/user/1001 is 
not listed.
  6.  systemd start user@1001.service<mailto:user@1001.service> which fails due 
to permission denied.

I can’t explain why the /run/user/1001 is owned by root after 
user-runtime-dir@1001.service<mailto: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<mailto:user@1001.service> 
then it works

root@host:/run/user# ls -la 1001
drwx--3 ida  root80 Dec 12 16:19 .
drwxr-xr-x3 root root60 Dec 12 16:19 ..
srw-rw-rw-1 ida  ssh-user 0 Dec 12 16:19 bus
drwxr-xr-x5 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 mailto:graw...@gmail.com>>
Date: Monday, 11 December 2023 at 17:56
To: Christopher Wong 
mailto:christopher.w...@axis.com>>
Cc: Systemd 
mailto:systemd-devel@lists.freedesktop.org>>
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Mon, Dec 11, 2023, 17:28 Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

I have added ExecStartPre to user@.service<mailto:user@.service> to run “id” 
and “ls -la”:

Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Will mount /run/user/1001 
owned by 1001:118
Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Mounting tmpfs (tmpfs) on 
/run/user/1001 (MS_NOSUID|MS_NODEV 
"mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...
Dec 11 15:50:34 host systemd[1]: Finished User Runtime Directory /run/user/1001.
Dec 11 15:50:34 host systemd[1]: Starting User Manager for UID 1001...
Dec 11 15:50:34 host id[40291]: uid=1001(ida) gid=118(ssh-users) 
groups=1

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Mantas Mikulėnas]

That sounds like it's getting immediately unmounted (or maybe not being
mounted at all despite the program doing so).

Does the user-runtime-dir service continue to show as "active" after this,
or does it return to "inactive"?

Does your /etc/fstab have any mentions of /run/user/1001? Or more
generally, are there any run-user-1001.mount units? (If you 'systemctl
status' this unit, does the status include a source path?)

On Tue, Dec 12, 2023, 17:34 Christopher Wong 
wrote:

> Hi Mantas,
>
>
>
> I currently have the following flow:
>
>
>
>1. No /run/user/1001 directory
>2. systemctl start user@1001.service
>3. systemd start user-runtime-dir@1001.service which ends successfully.
>4. The directory /run/user/1001 exists now, but is empty, owned by
>root with mode 0700
>5. I don’t have findmnt on my system, so I used mount, but
>/run/user/1001 is not listed.
>6. systemd start user@1001.service which fails due to permission
>denied.
>
>
>
> 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  root80 Dec 12 16:19 .
>
> drwxr-xr-x3 root root60 Dec 12 16:19 ..
>
> srw-rw-rw-1 ida  ssh-user 0 Dec 12 16:19 bus
>
> drwxr-xr-x5 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 
> *Date: *Monday, 11 December 2023 at 17:56
> *To: *Christopher Wong 
> *Cc: *Systemd 
> *Subject: *Re: [systemd-devel] Manual start of user@.service failed
> with permission denied
>
> On Mon, Dec 11, 2023, 17:28 Christopher Wong 
> wrote:
>
> Hi Mantas,
>
>
>
> I have added ExecStartPre to user@.service to run “id” and “ls -la”:
>
>
>
> Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Will mount
> /run/user/1001 owned by 1001:118
>
> Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Mounting tmpfs
> (tmpfs) on /run/user/1001 (MS_NOSUID|MS_NODEV
> "mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...
>
> Dec 11 15:50:34 host systemd[1]: Finished User Runtime Directory
> /run/user/1001.
>
> Dec 11 15:50:34 host systemd[1]: Starting User Manager for UID 1001...
>
> Dec 11 15:50:34 host id[40291]: uid=1001(ida) gid=118(ssh-users)
> groups=118(ssh-users),236(systemd-journal)
>
> Dec 11 15:50:34 host ls[40293]: drwxr-xr-x3 root root
> 60 Dec 11 15:50 .
>
> Dec 11 15:50:34 host ls[40293]: drwxr-xr-x   98 root root
> 2120 Dec 11 15:30 ..
>
> Dec 11 15:50:34 host ls[40293]: drwx--2 root root
> 40 Dec 11 15:50 1001
>
> Dec 11 15:50:34 host systemd[40294]: systemd 254.7-2-g9edc143 running in
> user mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK
> +SECCOMP +GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2
> -IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT
> -QRENCODE -TPM2 +BZIP2 -LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP
> -SYSVINIT default-hierarchy=unified)
>
>
>
> The /run/user/1001 belongs to root with mode 0700. Should this belong to
> root?
>
> No, it should be owned by UID 1001 (though still mode 0700).
>
> Is it because I manually start user@1001.service as root?
>
> 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).
>
> However, after user-runt

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Andrei,

The systemd logs tells me that /run/user/1001 is mounted as uid=1001, but when 
I list the path /run/user/1001 it is empty and is owned by root. I can’t find 
the path when I run the “mount” command. However, even for the successful case 
the path is not listed with the “mount” command.

Best regards,
Christopher Wong


From: Andrei Borzenkov 
Date: Monday, 11 December 2023 at 19:34
To: Christopher Wong , Mantas Mikulėnas 

Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On 11.12.2023 18:28, Christopher Wong wrote:
> Hi Mantas,
>
> I have added ExecStartPre to user@.service<mailto:user@.service> to run “id” 
> and “ls -la”:
>
> Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Will mount 
> /run/user/1001 owned by 1001:118
> Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Mounting tmpfs (tmpfs) 
> on /run/user/1001 (MS_NOSUID|MS_NODEV 
> "mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...
> Dec 11 15:50:34 host systemd[1]: Finished User Runtime Directory 
> /run/user/1001.
> Dec 11 15:50:34 host systemd[1]: Starting User Manager for UID 1001...
> Dec 11 15:50:34 host id[40291]: uid=1001(ida) gid=118(ssh-users) 
> groups=118(ssh-users),236(systemd-journal)
> Dec 11 15:50:34 host ls[40293]: drwxr-xr-x3 root root60 
> Dec 11 15:50 .
> Dec 11 15:50:34 host ls[40293]: drwxr-xr-x   98 root root  2120 
> Dec 11 15:30 ..
> Dec 11 15:50:34 host ls[40293]: drwx--2 root root40 
> Dec 11 15:50 1001
> Dec 11 15:50:34 host systemd[40294]: systemd 254.7-2-g9edc143 running in user 
> mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK +SECCOMP 
> +GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC 
> +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -TPM2 
> +BZIP2 -LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP -SYSVINIT 
> default-hierarchy=unified)
>
> The /run/user/1001 belongs to root with mode 0700. Should this belong to root?

No.

> Is it because I manually start user@1001.service<mailto:user@1001.service> as 
> root?

No.

> However, after 
> user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> has 
> finished it startup,  the user@1001.service<mailto:user@1001.service> is 
> started as uid=1001 and therefore can’t create any directories under 
> /run/user/1001. Resulting in user@1001.service<mailto:user@1001.service> 
> failed to start.
>
> If I add “ExecStartPre=+chown %i /run/user/%i” to 
> user@.service<mailto:user@.service> then it works! But I am unsure if this is 
> really the way fix this.

As clearly seen from logs, systemd-user-runtime-dir mounts tmpfs with
option uid=1001 over /run/user/1001. Is it still a mounted filesystem
when you check it? It sounds like you see mount point which indeed has
permissions 700 and owner root, not mounted filesystem.

>
> Regarding the testing, I have done both restart of everything and manual, but 
> the result is the same. Now that I have the 
> “Environment=XDG_RUNTIME_DIR=/run/user/%i” I no longer need to do “systemctl 
> set-environment …”
>
> Thank you for taking your time!
>
> Best regards,
> Christopher Wong
>
>
> From: Mantas Mikulėnas 
> Date: Friday, 8 December 2023 at 21:53
> To: Christopher Wong 
> Cc: Systemd 
> Subject: Re: [systemd-devel] Manual start of user@.service failed with 
> permission denied
> On Fri, Dec 8, 2023 at 6:53 PM Christopher Wong 
> mailto:christopher.w...@axis.com>> wrote:
> Hi Mantas,
>
> I have from your suggestion done the following:
>
> Putting the below in user@.service
>
> [Service]
> ...
> Environment=XDG_RUNTIME_DIR=/run/user/%i
> Environment=SYSTEMD_LOG_LEVEL=debug
>
> Putting the below in user-runtime-dir@.service
>
> [Service]
> ...
> Environment=SYSTEMD_LOG_LEVEL=debug
>
> Then I have disabled the global set-log-level debug (if this is also 
> required, please let me know).
>
> Unlike set-environment that's not global, it only affects pid1.
>
>
> What I can see from the logs is that 
> user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> seems to 
> be started and mount /run/user/1001, but addition creation of directory under 
> this mount is getting permission denied.
>
> Dec 08 17:33:29 host systemd[1]: Created slice User Slice of UID 1001.
> Dec 08 17:33:29 host systemd[1]: Starting User Runtime Directory 
> /run/user/1001...
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
> UNSET -> OPENING
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: sd-bus: starting bus by 
> connecting to /run/dbus

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Belanger,

Thank you for your suggestion! I tried putting RuntimeDirectory= into the 
user@.service<mailto:user@.service>. I suppose I shouldn’t need to do this 
since the runtime directory should be fixed by the service 
user-runtime-dir@.service<mailto:user-runtime-dir@.service>. Result is that it 
didn’t work.

Best regards,
Christopher Wong


From: Belanger, Martin 
Date: Monday, 11 December 2023 at 17:43
To: Christopher Wong , Mantas Mikulėnas 

Cc: Systemd 
Subject: RE: [systemd-devel] Manual start of user@.service failed with 
permission denied
Have you tried using "RuntimeDirectory=" (and optionally 
"RuntimeDirectoryPreserve=")

Ref: 
https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#RuntimeDirectory=

Regards,
Martin

From: systemd-devel  On Behalf Of 
Christopher Wong
Sent: Monday, December 11, 2023 10:28 AM
To: Mantas Mikulėnas 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied

[EXTERNAL EMAIL]
Hi Mantas,

I have added ExecStartPre to mailto:user@.service to run “id” and “ls -la”:

Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Will mount /run/user/1001 
owned by 1001:118
Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Mounting tmpfs (tmpfs) on 
/run/user/1001 (MS_NOSUID|MS_NODEV 
"mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...
Dec 11 15:50:34 host systemd[1]: Finished User Runtime Directory /run/user/1001.
Dec 11 15:50:34 host systemd[1]: Starting User Manager for UID 1001...
Dec 11 15:50:34 host id[40291]: uid=1001(ida) gid=118(ssh-users) 
groups=118(ssh-users),236(systemd-journal)
Dec 11 15:50:34 host ls[40293]: drwxr-xr-x3 root root60 Dec 
11 15:50 .
Dec 11 15:50:34 host ls[40293]: drwxr-xr-x   98 root root  2120 Dec 
11 15:30 ..
Dec 11 15:50:34 host ls[40293]: drwx--2 root root40 Dec 
11 15:50 1001
Dec 11 15:50:34 host systemd[40294]: systemd 254.7-2-g9edc143 running in user 
mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK +SECCOMP 
+GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC 
+KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -TPM2 +BZIP2 
-LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP -SYSVINIT 
default-hierarchy=unified)

The /run/user/1001 belongs to root with mode 0700. Should this belong to root? 
Is it because I manually start mailto:user@1001.service as root?
However, after mailto:user-runtime-dir@1001.service has finished it startup,  
the mailto:user@1001.service is started as uid=1001 and therefore can’t create 
any directories under /run/user/1001. Resulting in mailto:user@1001.service 
failed to start.

If I add “ExecStartPre=+chown %i /run/user/%i” to mailto:user@.service then it 
works! But I am unsure if this is really the way fix this.

Regarding the testing, I have done both restart of everything and manual, but 
the result is the same. Now that I have the 
“Environment=XDG_RUNTIME_DIR=/run/user/%i” I no longer need to do “systemctl 
set-environment …”

Thank you for taking your time!

Best regards,
Christopher Wong


From: Mantas Mikulėnas <mailto:graw...@gmail.com>
Date: Friday, 8 December 2023 at 21:53
To: Christopher Wong <mailto:christopher.w...@axis.com>
Cc: Systemd <mailto:systemd-devel@lists.freedesktop.org>
Subject: Re: [systemd-devel] Manual start of mailto:user@.service failed 
with permission denied
On Fri, Dec 8, 2023 at 6:53 PM Christopher Wong 
<mailto:christopher.w...@axis.com> wrote:
Hi Mantas,

I have from your suggestion done the following:

Putting the below in mailto:user@.service

[Service]
...
Environment=XDG_RUNTIME_DIR=/run/user/%i
Environment=SYSTEMD_LOG_LEVEL=debug

Putting the below in mailto:user-runtime-dir@.service

[Service]
...
Environment=SYSTEMD_LOG_LEVEL=debug

Then I have disabled the global set-log-level debug (if this is also required, 
please let me know).

Unlike set-environment that's not global, it only affects pid1.


What I can see from the logs is that mailto:user-runtime-dir@1001.service seems 
to be started and mount /run/user/1001, but addition creation of directory 
under this mount is getting permission denied.

Dec 08 17:33:29 host systemd[1]: Created slice User Slice of UID 1001.
Dec 08 17:33:29 host systemd[1]: Starting User Runtime Directory 
/run/user/1001...
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
UNSET -> OPENING
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: sd-bus: starting bus by 
connecting to /run/dbus/system_bus_socket...
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
OPENING -> AUTHENTICATING
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
AUTHENTICATING -> HELLO
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message 
type=method_call sender=n/a destination=org.freedesktop.D

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Mantas,

I currently have the following flow:


  1.  No /run/user/1001 directory
  2.  systemctl start user@1001.service<mailto:user@1001.service>
  3.  systemd start 
user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> which ends 
successfully.
  4.  The directory /run/user/1001 exists now, but is empty, owned by root with 
mode 0700
  5.  I don’t have findmnt on my system, so I used mount, but /run/user/1001 is 
not listed.
  6.  systemd start user@1001.service<mailto:user@1001.service> which fails due 
to permission denied.

I can’t explain why the /run/user/1001 is owned by root after 
user-runtime-dir@1001.service<mailto: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<mailto:user@1001.service> 
then it works

root@host:/run/user# ls -la 1001
drwx--3 ida  root80 Dec 12 16:19 .
drwxr-xr-x3 root root60 Dec 12 16:19 ..
srw-rw-rw-1 ida  ssh-user 0 Dec 12 16:19 bus
drwxr-xr-x5 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 
Date: Monday, 11 December 2023 at 17:56
To: Christopher Wong 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Mon, Dec 11, 2023, 17:28 Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

I have added ExecStartPre to user@.service<mailto:user@.service> to run “id” 
and “ls -la”:

Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Will mount /run/user/1001 
owned by 1001:118
Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Mounting tmpfs (tmpfs) on 
/run/user/1001 (MS_NOSUID|MS_NODEV 
"mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...
Dec 11 15:50:34 host systemd[1]: Finished User Runtime Directory /run/user/1001.
Dec 11 15:50:34 host systemd[1]: Starting User Manager for UID 1001...
Dec 11 15:50:34 host id[40291]: uid=1001(ida) gid=118(ssh-users) 
groups=118(ssh-users),236(systemd-journal)
Dec 11 15:50:34 host ls[40293]: drwxr-xr-x3 root root60 Dec 
11 15:50 .
Dec 11 15:50:34 host ls[40293]: drwxr-xr-x   98 root root  2120 Dec 
11 15:30 ..
Dec 11 15:50:34 host ls[40293]: drwx--2 root root40 Dec 
11 15:50 1001
Dec 11 15:50:34 host systemd[40294]: systemd 254.7-2-g9edc143 running in user 
mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK +SECCOMP 
+GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC 
+KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -TPM2 +BZIP2 
-LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP -SYSVINIT 
default-hierarchy=unified)

The /run/user/1001 belongs to root with mode 0700. Should this belong to root?
No, it should be owned by UID 1001 (though still mode 0700).
Is it because I manually start user@1001.service<mailto:user@1001.service> as 
root?
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).
However, after 
user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> has 
finished it startup,  the user@1001.service<mailto:user@1001.service> is 
started as uid=1001 and therefore can’t create any directories under 
/run/user/1001. Resulting in user@1001.service<mailto:user@1001.service> failed 
to start.

If I add “ExecStartPre=+chown %i /run/user/%i” to 
user@.service<mailto:user@.service> then it works! But I am unsure if this is 
really the way fix this.

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 
cronjob

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Andrei Borzenkov]

On 11.12.2023 18:28, Christopher Wong wrote:

Hi Mantas,

I have added ExecStartPre to user@.service<mailto:user@.service> to run “id” 
and “ls -la”:

Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Will mount /run/user/1001 
owned by 1001:118
Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Mounting tmpfs (tmpfs) on 
/run/user/1001 (MS_NOSUID|MS_NODEV 
"mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...
Dec 11 15:50:34 host systemd[1]: Finished User Runtime Directory /run/user/1001.
Dec 11 15:50:34 host systemd[1]: Starting User Manager for UID 1001...
Dec 11 15:50:34 host id[40291]: uid=1001(ida) gid=118(ssh-users) 
groups=118(ssh-users),236(systemd-journal)
Dec 11 15:50:34 host ls[40293]: drwxr-xr-x3 root root60 Dec 
11 15:50 .
Dec 11 15:50:34 host ls[40293]: drwxr-xr-x   98 root root  2120 Dec 
11 15:30 ..
Dec 11 15:50:34 host ls[40293]: drwx--2 root root40 Dec 
11 15:50 1001
Dec 11 15:50:34 host systemd[40294]: systemd 254.7-2-g9edc143 running in user 
mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK +SECCOMP 
+GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC 
+KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -TPM2 +BZIP2 
-LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP -SYSVINIT 
default-hierarchy=unified)

The /run/user/1001 belongs to root with mode 0700. Should this belong to root? 


No.


Is it because I manually start user@1001.service<mailto:user@1001.service> as 
root?


No.


However, after user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> has 
finished it startup,  the user@1001.service<mailto:user@1001.service> is started as 
uid=1001 and therefore can’t create any directories under /run/user/1001. Resulting in 
user@1001.service<mailto:user@1001.service> failed to start.

If I add “ExecStartPre=+chown %i /run/user/%i” to 
user@.service<mailto:user@.service> then it works! But I am unsure if this is 
really the way fix this.


As clearly seen from logs, systemd-user-runtime-dir mounts tmpfs with 
option uid=1001 over /run/user/1001. Is it still a mounted filesystem 
when you check it? It sounds like you see mount point which indeed has 
permissions 700 and owner root, not mounted filesystem.




Regarding the testing, I have done both restart of everything and manual, but 
the result is the same. Now that I have the 
“Environment=XDG_RUNTIME_DIR=/run/user/%i” I no longer need to do “systemctl 
set-environment …”

Thank you for taking your time!

Best regards,
Christopher Wong


From: Mantas Mikulėnas 
Date: Friday, 8 December 2023 at 21:53
To: Christopher Wong 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Fri, Dec 8, 2023 at 6:53 PM Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

I have from your suggestion done the following:

Putting the below in user@.service

[Service]
...
Environment=XDG_RUNTIME_DIR=/run/user/%i
Environment=SYSTEMD_LOG_LEVEL=debug

Putting the below in user-runtime-dir@.service

[Service]
...
Environment=SYSTEMD_LOG_LEVEL=debug

Then I have disabled the global set-log-level debug (if this is also required, 
please let me know).

Unlike set-environment that's not global, it only affects pid1.


What I can see from the logs is that 
user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> seems to be 
started and mount /run/user/1001, but addition creation of directory under this mount 
is getting permission denied.

Dec 08 17:33:29 host systemd[1]: Created slice User Slice of UID 1001.
Dec 08 17:33:29 host systemd[1]: Starting User Runtime Directory 
/run/user/1001...
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
UNSET -> OPENING
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: sd-bus: starting bus by 
connecting to /run/dbus/system_bus_socket...
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
OPENING -> AUTHENTICATING
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
AUTHENTICATING -> HELLO
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message 
type=method_call sender=n/a destination=org.freedesktop.DBus 
path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 
reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Got message 
type=method_return sender=org.freedesktop.DBus destination=:1.2536 path=n/a 
interface=n/a member=n/a  cookie=1 reply_cookie=1 signature=s error-name=n/a 
error-message=n/a
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
HELLO -> RUNNING
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message 
type=method_call sender=n/a destination=org.freedesktop.login1 
path=/org/freedesktop

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Mantas Mikulėnas]

On Mon, Dec 11, 2023, 17:28 Christopher Wong 
wrote:

> Hi Mantas,
>
>
>
> I have added ExecStartPre to user@.service to run “id” and “ls -la”:
>
>
>
> Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Will mount
> /run/user/1001 owned by 1001:118
>
> Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Mounting tmpfs
> (tmpfs) on /run/user/1001 (MS_NOSUID|MS_NODEV
> "mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...
>
> Dec 11 15:50:34 host systemd[1]: Finished User Runtime Directory
> /run/user/1001.
>
> Dec 11 15:50:34 host systemd[1]: Starting User Manager for UID 1001...
>
> Dec 11 15:50:34 host id[40291]: uid=1001(ida) gid=118(ssh-users)
> groups=118(ssh-users),236(systemd-journal)
>
> Dec 11 15:50:34 host ls[40293]: drwxr-xr-x3 root root
> 60 Dec 11 15:50 .
>
> Dec 11 15:50:34 host ls[40293]: drwxr-xr-x   98 root root
> 2120 Dec 11 15:30 ..
>
> Dec 11 15:50:34 host ls[40293]: drwx--2 root root
> 40 Dec 11 15:50 1001
>
> Dec 11 15:50:34 host systemd[40294]: systemd 254.7-2-g9edc143 running in
> user mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK
> +SECCOMP +GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2
> -IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT
> -QRENCODE -TPM2 +BZIP2 -LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP
> -SYSVINIT default-hierarchy=unified)
>
>
>
> The /run/user/1001 belongs to root with mode 0700. Should this belong to
> root?
>
No, it should be owned by UID 1001 (though still mode 0700).

> Is it because I manually start user@1001.service as root?
>
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).

> However, after user-runtime-dir@1001.service has finished it startup,
> the user@1001.service is started as uid=1001 and therefore can’t create
> any directories under /run/user/1001. Resulting in user@1001.service
> failed to start.
>
>
>
> If I add “ExecStartPre=+chown %i /run/user/%i” to user@.service then it
> works! But I am unsure if this is really the way fix this.
>

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.


>
> Regarding the testing, I have done both restart of everything and manual,
> but the result is the same. Now that I have the
> “Environment=XDG_RUNTIME_DIR=/run/user/%i” I no longer need to do
> “systemctl set-environment …”
>
>
>
> Thank you for taking your time!
>
>
>
> Best regards,
>
> Christopher Wong
>
>
>
>
>
> *From: *Mantas Mikulėnas 
> *Date: *Friday, 8 December 2023 at 21:53
> *To: *Christopher Wong 
> *Cc: *Systemd 
> *Subject: *Re: [systemd-devel] Manual start of user@.service failed
> with permission denied
>
> On Fri, Dec 8, 2023 at 6:53 PM Christopher Wong 
> wrote:
>
> Hi Mantas,
>
>
>
> I have from your suggestion done the following:
>
>
>
> Putting the below in user@.service
>
>
>
> [Service]
>
> ...
>
> Environment=XDG_RUNTIME_DIR=/run/user/%i
>
> Environment=SYSTEMD_LOG_LEVEL=debug
>
>
>
> Putting the below in user-runtime-dir@.service
>
>
>
> [Service]
>
> ...
>
> Environment=SYSTEMD_LOG_LEVEL=debug
>
>
>
> Then I have disabled the global set-log-level debug (if this is also
> required, please let me know).
>
>
>
> Unlike set-environment that's not global, it only affects pid1.
>
>
>
>
>
> What I can see from the logs is that user-runtime-dir@1001.service seems
> to be sta

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Andrei,

As indicated in the logs no SELINUX nor APPARMOR is enabled.

Best regards,
Christopher Wong


From: systemd-devel  on behalf of 
Andrei Borzenkov 
Date: Saturday, 9 December 2023 at 07:13
To: systemd-devel@lists.freedesktop.org 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On 08.12.2023 23:53, Mantas Mikulėnas wrote:
...

>>
>> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Will mount
>> /run/user/1001 owned by 1001:118
>>
>> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Mounting tmpfs
>> (tmpfs) on /run/user/1001 (MS_NOSUID|MS_NODEV
>> "mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...
>>
>> Dec 08 17:33:29 host systemd[1]: Finished User Runtime Directory
>> /run/user/1001.
>>
>> Dec 08 17:33:29 host systemd[1]: Starting User Manager for UID 1001...
>>
>> Dec 08 17:33:29 host systemd[36280]: systemd 254.7-2-g9edc143 running in
>> user mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK
>> +SECCOMP +GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2
>> -IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT
>> -QRENCODE -TPM2 +BZIP2 -LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP
>> -SYSVINIT default-hierarchy=unified)
>>
>> Dec 08 17:33:29 host systemd[36280]: Failed to create
>> '/run/user/1001/systemd/inaccessible', ignoring: Permission denied
>>
>> Dec 08 17:33:29 host systemd[36280]: Failed to create
>> '/run/user/1001/systemd/inaccessible/reg', ignoring: Permission denied
>>
>> Dec 08 17:33:29 host systemd[36280]: Failed to create
>> '/run/user/1001/systemd/inaccessible/dir', ignoring: Permission denied
>>
>> Dec 08 17:33:29 host systemd[36280]: Failed to create
>> '/run/user/1001/systemd/inaccessible/fifo', ignoring: Permission denied
>>
>> Dec 08 17:33:29 host systemd[36280]: Failed to create
>> '/run/user/1001/systemd/inaccessible/sock', ignoring: Permission denied
>>
>> Dec 08 17:33:29 host systemd[36280]: Failed to create
>> '/run/user/1001/systemd/inaccessible/chr', ignoring: Permission denied
>>
>> Dec 08 17:33:29 host systemd[36280]: Failed to create
>> '/run/user/1001/systemd/inaccessible/blk', ignoring: Permission denied
>>
>
> What's the ownership of /run/user/1001 and /run/user/1001/systemd after all
> of this?
>
> Are you rebooting between tests or just manually starting it?
>
> My current guess is that due to the earlier `systemctl set-environment`,
> some *other* thing that's running as root inherited the /run/user/1001 path
> and created root-owned directories there? That's the issue with setting
> global environment, it needs to be unset afterwards...
>

"Permission denied" sounds like something LSM related (AppArmor,
SELinux, ...)

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Mantas,

I have added ExecStartPre to user@.service<mailto:user@.service> to run “id” 
and “ls -la”:

Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Will mount /run/user/1001 
owned by 1001:118
Dec 11 15:50:34 host systemd-user-runtime-dir[40287]: Mounting tmpfs (tmpfs) on 
/run/user/1001 (MS_NOSUID|MS_NODEV 
"mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...
Dec 11 15:50:34 host systemd[1]: Finished User Runtime Directory /run/user/1001.
Dec 11 15:50:34 host systemd[1]: Starting User Manager for UID 1001...
Dec 11 15:50:34 host id[40291]: uid=1001(ida) gid=118(ssh-users) 
groups=118(ssh-users),236(systemd-journal)
Dec 11 15:50:34 host ls[40293]: drwxr-xr-x3 root root60 Dec 
11 15:50 .
Dec 11 15:50:34 host ls[40293]: drwxr-xr-x   98 root root  2120 Dec 
11 15:30 ..
Dec 11 15:50:34 host ls[40293]: drwx--2 root root40 Dec 
11 15:50 1001
Dec 11 15:50:34 host systemd[40294]: systemd 254.7-2-g9edc143 running in user 
mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK +SECCOMP 
+GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC 
+KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -TPM2 +BZIP2 
-LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP -SYSVINIT 
default-hierarchy=unified)

The /run/user/1001 belongs to root with mode 0700. Should this belong to root? 
Is it because I manually start user@1001.service<mailto:user@1001.service> as 
root?
However, after 
user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> has 
finished it startup,  the user@1001.service<mailto:user@1001.service> is 
started as uid=1001 and therefore can’t create any directories under 
/run/user/1001. Resulting in user@1001.service<mailto:user@1001.service> failed 
to start.

If I add “ExecStartPre=+chown %i /run/user/%i” to 
user@.service<mailto:user@.service> then it works! But I am unsure if this is 
really the way fix this.

Regarding the testing, I have done both restart of everything and manual, but 
the result is the same. Now that I have the 
“Environment=XDG_RUNTIME_DIR=/run/user/%i” I no longer need to do “systemctl 
set-environment …”

Thank you for taking your time!

Best regards,
Christopher Wong


From: Mantas Mikulėnas 
Date: Friday, 8 December 2023 at 21:53
To: Christopher Wong 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Fri, Dec 8, 2023 at 6:53 PM Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

I have from your suggestion done the following:

Putting the below in user@.service

[Service]
...
Environment=XDG_RUNTIME_DIR=/run/user/%i
Environment=SYSTEMD_LOG_LEVEL=debug

Putting the below in user-runtime-dir@.service

[Service]
...
Environment=SYSTEMD_LOG_LEVEL=debug

Then I have disabled the global set-log-level debug (if this is also required, 
please let me know).

Unlike set-environment that's not global, it only affects pid1.


What I can see from the logs is that 
user-runtime-dir@1001.service<mailto:user-runtime-dir@1001.service> seems to be 
started and mount /run/user/1001, but addition creation of directory under this 
mount is getting permission denied.

Dec 08 17:33:29 host systemd[1]: Created slice User Slice of UID 1001.
Dec 08 17:33:29 host systemd[1]: Starting User Runtime Directory 
/run/user/1001...
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
UNSET -> OPENING
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: sd-bus: starting bus by 
connecting to /run/dbus/system_bus_socket...
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
OPENING -> AUTHENTICATING
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
AUTHENTICATING -> HELLO
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message 
type=method_call sender=n/a destination=org.freedesktop.DBus 
path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 
reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Got message 
type=method_return sender=org.freedesktop.DBus destination=:1.2536 path=n/a 
interface=n/a member=n/a  cookie=1 reply_cookie=1 signature=s error-name=n/a 
error-message=n/a
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
HELLO -> RUNNING
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message 
type=method_call sender=n/a destination=org.freedesktop.login1 
path=/org/freedesktop/login1 interface=org.freedesktop.DBus.Properties 
member=Get cookie=2 reply_cookie=0 signature=ss error-name=n/a error-message=n/a
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Got message 
type=method_return sender=:1.323 destination=:1.2536 path=n/a interface=n/a 
member=n/a  cookie=15 reply_cookie=2 signature=v error-name=n/a 

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Andrei Borzenkov]

On 08.12.2023 23:53, Mantas Mikulėnas wrote:
...



Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Will mount
/run/user/1001 owned by 1001:118

Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Mounting tmpfs
(tmpfs) on /run/user/1001 (MS_NOSUID|MS_NODEV
"mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...

Dec 08 17:33:29 host systemd[1]: Finished User Runtime Directory
/run/user/1001.

Dec 08 17:33:29 host systemd[1]: Starting User Manager for UID 1001...

Dec 08 17:33:29 host systemd[36280]: systemd 254.7-2-g9edc143 running in
user mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK
+SECCOMP +GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2
-IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT
-QRENCODE -TPM2 +BZIP2 -LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP
-SYSVINIT default-hierarchy=unified)

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible', ignoring: Permission denied

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible/reg', ignoring: Permission denied

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible/dir', ignoring: Permission denied

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible/fifo', ignoring: Permission denied

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible/sock', ignoring: Permission denied

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible/chr', ignoring: Permission denied

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible/blk', ignoring: Permission denied



What's the ownership of /run/user/1001 and /run/user/1001/systemd after all
of this?

Are you rebooting between tests or just manually starting it?

My current guess is that due to the earlier `systemctl set-environment`,
some *other* thing that's running as root inherited the /run/user/1001 path
and created root-owned directories there? That's the issue with setting
global environment, it needs to be unset afterwards...



"Permission denied" sounds like something LSM related (AppArmor, 
SELinux, ...)

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Mantas Mikulėnas]

On Fri, Dec 8, 2023 at 6:53 PM Christopher Wong 
wrote:

> Hi Mantas,
>
>
>
> I have from your suggestion done the following:
>
>
>
> Putting the below in user@.service
>
>
>
> [Service]
>
> ...
>
> Environment=XDG_RUNTIME_DIR=/run/user/%i
>
> Environment=SYSTEMD_LOG_LEVEL=debug
>
>
>
> Putting the below in user-runtime-dir@.service
>
>
>
> [Service]
>
> ...
>
> Environment=SYSTEMD_LOG_LEVEL=debug
>
>
>
> Then I have disabled the global set-log-level debug (if this is also
> required, please let me know).
>

Unlike set-environment that's not global, it only affects pid1.



> What I can see from the logs is that user-runtime-dir@1001.service seems
> to be started and mount /run/user/1001, but addition creation of directory
> under this mount is getting permission denied.
>
>
>
> Dec 08 17:33:29 host systemd[1]: Created slice User Slice of UID 1001.
>
> Dec 08 17:33:29 host systemd[1]: Starting User Runtime Directory
> /run/user/1001...
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing
> state UNSET -> OPENING
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: sd-bus: starting bus
> by connecting to /run/dbus/system_bus_socket...
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing
> state OPENING -> AUTHENTICATING
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing
> state AUTHENTICATING -> HELLO
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message
> type=method_call sender=n/a destination=org.freedesktop.DBus
> path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello
> cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Got message
> type=method_return sender=org.freedesktop.DBus destination=:1.2536 path=n/a
> interface=n/a member=n/a  cookie=1 reply_cookie=1 signature=s
> error-name=n/a error-message=n/a
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing
> state HELLO -> RUNNING
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message
> type=method_call sender=n/a destination=org.freedesktop.login1
> path=/org/freedesktop/login1 interface=org.freedesktop.DBus.Properties
> member=Get cookie=2 reply_cookie=0 signature=ss error-name=n/a
> error-message=n/a
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Got message
> type=method_return sender=:1.323 destination=:1.2536 path=n/a interface=n/a
> member=n/a  cookie=15 reply_cookie=2 signature=v error-name=n/a
> error-message=n/a
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message
> type=method_call sender=n/a destination=org.freedesktop.login1
> path=/org/freedesktop/login1 interface=org.freedesktop.DBus.Properties
> member=Get cookie=3 reply_cookie=0 signature=ss error-name=n/a
> error-message=n/a
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Got message
> type=method_return sender=:1.323 destination=:1.2536 path=n/a interface=n/a
> member=n/a  cookie=16 reply_cookie=3 signature=v error-name=n/a
> error-message=n/a
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing
> state RUNNING -> CLOSED
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Will mount
> /run/user/1001 owned by 1001:118
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Mounting tmpfs
> (tmpfs) on /run/user/1001 (MS_NOSUID|MS_NODEV
> "mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...
>
> Dec 08 17:33:29 host systemd[1]: Finished User Runtime Directory
> /run/user/1001.
>
> Dec 08 17:33:29 host systemd[1]: Starting User Manager for UID 1001...
>
> Dec 08 17:33:29 host systemd[36280]: systemd 254.7-2-g9edc143 running in
> user mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK
> +SECCOMP +GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2
> -IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT
> -QRENCODE -TPM2 +BZIP2 -LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP
> -SYSVINIT default-hierarchy=unified)
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible', ignoring: Permission denied
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible/reg', ignoring: Permission denied
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible/dir', ignoring: Permission denied
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible/fifo', ignoring: Permission denied
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible/sock', ignoring: Permission denied
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible/chr', ignoring: Permission denied
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible/blk', ignoring: Permission denied
>

What's the ownership of 

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

6280]: Failed at setting rlimit 1073741816 for 
resource RLIMIT_NOFILE. Will attempt setting value 524288 instead.
Dec 08 17:33:29 host systemd[36280]: Found cgroup2 on /sys/fs/cgroup/, full 
unified hierarchy
Dec 08 17:33:29 host systemd[36280]: Unified cgroup hierarchy is located at 
/sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service.
Dec 08 17:33:29 host systemd[36280]: bpf-firewall: Got EBADF when using 
BPF_F_ALLOW_MULTI, which indicates it is supported. Yay!
Dec 08 17:33:29 host systemd[36280]: Not enough privileges, BPF device control 
is not supported.
Dec 08 17:33:29 host systemd[36280]: Controller 'cpu' supported: yes
Dec 08 17:33:29 host systemd[36280]: Controller 'cpuacct' supported: no
Dec 08 17:33:29 host systemd[36280]: Controller 'cpuset' supported: no
Dec 08 17:33:29 host systemd[36280]: Controller 'io' supported: no
Dec 08 17:33:29 host systemd[36280]: Controller 'blkio' supported: no
Dec 08 17:33:29 host systemd[36280]: Controller 'memory' supported: yes
Dec 08 17:33:29 host systemd[36280]: Controller 'devices' supported: no
Dec 08 17:33:29 host systemd[36280]: Controller 'pids' supported: yes
Dec 08 17:33:29 host systemd[36280]: Controller 'bpf-firewall' supported: yes
Dec 08 17:33:29 host systemd[36280]: Controller 'bpf-devices' supported: no
Dec 08 17:33:29 host systemd[36280]: Controller 'bpf-foreign' supported: yes
Dec 08 17:33:29 host systemd[36280]: Controller 'bpf-socket-bind' supported: no
Dec 08 17:33:29 host systemd[36280]: Controller 
'bpf-restrict-network-interfaces' supported: no
Dec 08 17:33:29 host systemd[36280]: Set up TFD_TIMER_CANCEL_ON_SET timerfd.
Dec 08 17:33:29 host systemd[36280]: Failed to establish memory pressure event 
source, ignoring: Operation not supported
Dec 08 17:33:29 host systemd[36280]: Failed to allocate manager object: 
Permission denied
Dec 08 17:33:29 host systemd[1]: user@1001.service: Main process exited, 
code=exited, status=1/FAILURE
Dec 08 17:33:29 host systemd[1]: user@1001.service: Failed with result 
'exit-code'.
Dec 08 17:33:29 host systemd[1]: Failed to start User Manager for UID 1001.
Dec 08 17:33:29 host systemd[1]: Stopping User Runtime Directory 
/run/user/1001...
Dec 08 17:33:29 host systemd-user-runtime-dir[36283]: Will remove /run/user/1001
Dec 08 17:33:29 host systemd[1]: user-runtime-dir@1001.service: Deactivated 
successfully.
Dec 08 17:33:29 host systemd[1]: Stopped User Runtime Directory /run/user/1001.
Dec 08 17:33:29 host systemd[1]: Removed slice User Slice of UID 1001.

Best regards,
Christopher Wong


From: Mantas Mikulėnas 
Date: Friday, 8 December 2023 at 12:11
To: Christopher Wong 
Cc: Luca Boccassi , Systemd 

Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Fri, Dec 8, 2023, 12:22 Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Luca,

Sorry, for late reply, below is a log with debug. This time I run with a user 
with higher UID, but the result is the same.

root@host:~# systemd-analyze set-log-level debug
root@host:~# systemctl set-environment XDG_RUNTIME_DIR="/run/user/1001"

I'd avoid doing that globally. If you really want to have a PAM-less system, 
then edit the unit to set this through its Environment= instead.

root@host:~# systemctl start user@1001.service
Job for user@1001.service failed because the control process exited with error 
code.
See "systemctl status user@1001.service" and "journalctl -xeu 
user@1001.service" for details.
root@host:~# journalctl -xeu user@1001.service
Dec 08 09:35:53 host systemd[1]: /usr/lib/systemd/system/user@.service:19: 
Support for option PAMName= has been disabled at compile time and it is ignored
Dec 08 09:35:53 host systemd[1]: user@1001.service: Trying to enqueue job 
user@1001.service/start/replace
Dec 08 09:35:53 host systemd[1]: user@1001.service: Installed new job 
user@1001.service/start as 6724
Dec 08 09:35:53 host systemd[1]: user@1001.service: Enqueued job 
user@1001.service/start as 6724
Dec 08 09:35:53 host systemd[1]: user@1001.service: starting held back, waiting 
for: user-runtime-dir@1001.service
Dec 08 09:35:54 host systemd[1]: user@1001.service: Will spawn child 
(service_enter_start): /usr/lib/systemd/systemd
Dec 08 09:35:54 host systemd[1]: user@1001.service: Failed to set 
'memory.zswap.max' attribute on '/user.slice/user-1001.slice/user@1001.service' 
to 'max': No such file or directory
Dec 08 09:35:54 host systemd[1]: user@1001.service: Passing 0 fds to service
Dec 08 09:35:54 host systemd[1]: user@1001.service: About to execute: 
/usr/lib/systemd/systemd --user
Dec 08 09:35:54 host systemd[1]: user@1001.service: Forked 
/usr/lib/systemd/systemd as 6899
Dec 08 09:35:54 host (systemd)[6899]: Found cgroup2 on /sys/fs/cgroup/, full 
unified hierarchy
Dec 08 09:35:54 host systemd[1]: user@1001.service: Changed dead -> start
Dec 08 09:35:54 host systemd[1]: Starting User Manager for UID 1001...
Dec 08 09:35:54 host (systemd)[6899]: Bind-mounting / on 

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Mantas Mikulėnas]

 Dec 08 09:35:54 host (systemd)[6899]: Mounting sysfs (sysfs) on
> /run/systemd/mount-rootfs/sys (MS_NOSUID|MS_NODEV|MS_NOEXEC "")...
>
> Dec 08 09:35:54 host (systemd)[6899]: user@1001.service: Executing:
> /usr/lib/systemd/systemd --user
>
> Dec 08 09:35:54 host systemd[6899]: Failed to copy os-release for
> propagation, ignoring: Permission denied
>
> Dec 08 09:35:54 host systemd[6899]: Failed to allocate manager object:
> Permission denied
>
Try setting SYSTEMD_LOG_LEVEL=debug for the user@ service unit to see what
happens here. (This is a separate instance so it doesn't inherit the debug
level that pid1 has...)

Also, I might've missed this, but does anything *create* /run/user/1001
here? Normally user-user-runtime-dir@1001.service would be the one to do
so, and I see "waiting for: user-runtime-dir@1001.service" in the logs, but
I don't see anything else – did that service actually succeed? is the path
owned by UID 1001?

> Dec 08 09:35:54 host systemd[1]: user@1001.service: Got notification
> message from PID 6899 (ERRNO=13)
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Got notification
> message from PID 6899 (EXIT_STATUS=1)
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Child 6899 belongs to
> user@1001.service.
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Main process exited,
> code=exited, status=1/FAILURE
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Failed with result
> 'exit-code'.
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Service will not
> restart (restart setting)
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Changed start ->
> failed
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Job 6724
> user@1001.service/start finished, result=failed
>
> Dec 08 09:35:54 host systemd[1]: Failed to start User Manager for UID 1001.
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Unit entered failed
> state.
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Consumed 63ms CPU
> time.
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Releasing resources...
>
>
>
> Best regards,
>
> Christopher Wong
>
>
>
>
>
>
>
> *From: *Luca Boccassi 
> *Date: *Wednesday, 6 December 2023 at 17:46
> *To: *Christopher Wong 
> *Cc: *systemd-devel@lists.freedesktop.org <
> systemd-devel@lists.freedesktop.org>
> *Subject: *Re: [systemd-devel] Manual start of user@.service failed
> with permission denied
>
> On Wed, 6 Dec 2023 at 16:00, Christopher Wong 
> wrote:
> > Hi,
> >
> > I’m trying to do the following:
> >
> > root@host:~# systemctl set-environment XDG_RUNTIME_DIR="/run/user/503"
>
> Why are you setting this?
> Anyway, enable debug level log and attach the output, otherwise it's hard
> to say
>

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Lennart Poettering]

On Fr, 08.12.23 08:52, Christopher Wong (christopher.w...@axis.com) wrote:

> Hi Lennart,
>
> I know we are not using the pam_systemd. That is the reason we try
> to run the steps manually. It was possible to start the
> user@.service in systemd v253, but it fails now with v254 or
> later.

Well, that's not supported then. You need XDG_RUNTIME_DIR set up
properly, and that's what the PAM module gives you. If you turn off
the PAM module then you get to keep the pieces, you voided your
warranty.

Lennart

--
Lennart Poettering, Berlin

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Aki Ketolainen]

On 2023-12-07 23:03, Lennart Poettering wrote:


The 503 is a system user. So, just to try it out, I created a user,
which got the UID 1001. Using that UID gave me the same result as
the 503.


It's a bad idea to run user stuff as system user.

Lennart


Why's that?

Best regards,

Aki

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Lennart,

I know we are not using the pam_systemd. That is the reason we try to run the 
steps manually. It was possible to start the user@.service in systemd 
v253, but it fails now with v254 or later.

Best regards,
Christopher Wong



From: Lennart Poettering 
Date: Thursday, 7 December 2023 at 22:03
To: Christopher Wong 
Cc: systemd-devel@lists.freedesktop.org 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Do, 07.12.23 18:29, Christopher Wong (christopher.w...@axis.com) wrote:

> Hi Lennart,
>
> We are doing the steps to start up a rootless docker. If I don’t set 
> XDG_RUNTIME_DIR then I will get the below error:
>
> systemd[1925]: Trying to run as user instance, but $XDG_RUNTIME_DIR
> is not set.

pam_systemd is responsible for setting this env var. Most likely you
are missing that from the PAM stack that is used by this user@.service
instance?

> The 503 is a system user. So, just to try it out, I created a user,
> which got the UID 1001. Using that UID gave me the same result as
> the 503.

It's a bad idea to run user stuff as system user.

Lennart

--
Lennart Poettering, Berlin

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

ystemd[1]: user@1001.service: Main process exited, 
code=exited, status=1/FAILURE
Dec 08 09:35:54 host systemd[1]: user@1001.service: Failed with result 
'exit-code'.
Dec 08 09:35:54 host systemd[1]: user@1001.service: Service will not restart 
(restart setting)
Dec 08 09:35:54 host systemd[1]: user@1001.service: Changed start -> failed
Dec 08 09:35:54 host systemd[1]: user@1001.service: Job 6724 
user@1001.service/start finished, result=failed
Dec 08 09:35:54 host systemd[1]: Failed to start User Manager for UID 1001.
Dec 08 09:35:54 host systemd[1]: user@1001.service: Unit entered failed state.
Dec 08 09:35:54 host systemd[1]: user@1001.service: Consumed 63ms CPU time.
Dec 08 09:35:54 host systemd[1]: user@1001.service: Releasing resources...

Best regards,
Christopher Wong



From: Luca Boccassi 
Date: Wednesday, 6 December 2023 at 17:46
To: Christopher Wong 
Cc: systemd-devel@lists.freedesktop.org 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Wed, 6 Dec 2023 at 16:00, Christopher Wong  wrote:
> Hi,
>
> I’m trying to do the following:
>
> root@host:~# systemctl set-environment XDG_RUNTIME_DIR="/run/user/503"

Why are you setting this?
Anyway, enable debug level log and attach the output, otherwise it's hard to say

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Lennart Poettering]

On Do, 07.12.23 18:29, Christopher Wong (christopher.w...@axis.com) wrote:

> Hi Lennart,
>
> We are doing the steps to start up a rootless docker. If I don’t set 
> XDG_RUNTIME_DIR then I will get the below error:
>
> systemd[1925]: Trying to run as user instance, but $XDG_RUNTIME_DIR
> is not set.

pam_systemd is responsible for setting this env var. Most likely you
are missing that from the PAM stack that is used by this user@.service
instance?

> The 503 is a system user. So, just to try it out, I created a user,
> which got the UID 1001. Using that UID gave me the same result as
> the 503.

It's a bad idea to run user stuff as system user.

Lennart

--
Lennart Poettering, Berlin

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Lennart,

We are doing the steps to start up a rootless docker. If I don’t set 
XDG_RUNTIME_DIR then I will get the below error:

systemd[1925]: Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

The 503 is a system user. So, just to try it out, I created a user, which got 
the UID 1001. Using that UID gave me the same result as the 503.

Best regards,
Christopher Wong



From: Lennart Poettering 
Date: Wednesday, 6 December 2023 at 16:50
To: Christopher Wong 
Cc: systemd-devel@lists.freedesktop.org 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Mi, 06.12.23 14:46, Christopher Wong (christopher.w...@axis.com) wrote:

> Hi,
>
> I’m trying to do the following:
>
> root@host:~# systemctl set-environment
> XDG_RUNTIME_DIR="/run/user/503"

Why would you do that?

user@.service automatically pulls in user-runtime-dir@.service which
is responsible for creating that dir with right perms.

is 504 a system user? or a regular user?

systemd generally assumes the boundary between system and regular
users is between 999 and 1000.

But user@.service is really just for regular users, not system users,
hence my question.

Lennart

--
Lennart Poettering, Berlin

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Luca Boccassi]

On Wed, 6 Dec 2023 at 16:00, Christopher Wong  wrote:
> Hi,
>
> I’m trying to do the following:
>
> root@host:~# systemctl set-environment XDG_RUNTIME_DIR="/run/user/503"

Why are you setting this?
Anyway, enable debug level log and attach the output, otherwise it's hard to say

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Lennart Poettering]

On Mi, 06.12.23 14:46, Christopher Wong (christopher.w...@axis.com) wrote:

> Hi,
>
> I’m trying to do the following:
>
> root@host:~# systemctl set-environment
> XDG_RUNTIME_DIR="/run/user/503"

Why would you do that?

user@.service automatically pulls in user-runtime-dir@.service which
is responsible for creating that dir with right perms.

is 504 a system user? or a regular user?

systemd generally assumes the boundary between system and regular
users is between 999 and 1000.

But user@.service is really just for regular users, not system users,
hence my question.

Lennart

--
Lennart Poettering, Berlin

[systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi,

I’m trying to do the following:

root@host:~# systemctl set-environment XDG_RUNTIME_DIR="/run/user/503"
root@host:~# systemctl start user@503.service

On systemd 253.4, the user can be started manually, and I can list the 
directory:

root@host:~# ls -la /run/user/503
drwx--3 debugar  debugar 80 Dec  4 09:08 .
drwxr-xr-x3 root root60 Dec  4 09:08 ..
srw-rw-rw-1 debugar  debugar  0 Dec  4 09:08 bus
drwxr-xr-x4 debugar  debugar120 Dec  4 09:08 systemd

On last systemd v254-stable and v255-stable, I got the following instead:

root@host:/var/log# journalctl -xeu user@503.service
Dec 06 12:40:41 host systemd[1]: Starting User Manager for UID 503...
Dec 06 12:40:41 host systemd[7939]: Failed to copy os-release for propagation, 
ignoring: Permission denied
Dec 06 12:40:41 host systemd[7939]: Failed to allocate manager object: 
Permission denied
Dec 06 12:40:41 host systemd[1]: user@503.service: 
Main process exited, code=exited, status=1/FAILURE
Dec 06 12:40:41 host systemd[1]: user@503.service: 
Failed with result 'exit-code'.
Dec 06 12:40:41 host systemd[1]: Failed to start User Manager for UID 503.

systemd was able to create the dir /run/user/503, but got errno -13 (Permission 
denied) when it was trying to do mkdirat with path /run/user/503/systemd in 
function mkdirat_label() in file mkdir-label.c.

Do I need to do something else before starting 
user@.service or is this a bug?

Best regards,
Christopher Wong