docs: clarify systemd unit placement and sudo requirements per permission (#613)

Explain which systemd unit location is used for each schedule-permission
value, and make it clear that `user` still requires sudo while
`user_logged_on` does not. Add a tip pointing users toward lingering as
the path to rootless always-on scheduling.

Author: fgrosse

docs/content/schedules/configuration.md

@@ -75,9 +75,9 @@ profile:
 
 * `system`: Access system or protected files. Run resticprofile with `sudo` on Unix and with elevated prompt on Windows. On Windows, resticprofile will automatically request elevated permissions if needed.
 
-* `user`: Run the backup using current user permissions. Suitable for saving documents or files within your profile. **This mode runs even when the user is not logged on**. It will ask for your user password on Windows. It needs root permission (via sudo) when using `systemd`.
+* `user`: Run the backup using current user permissions. Suitable for saving documents or files within your profile. **This mode runs even when the user is not logged on**. It will ask for your user password on Windows. On Linux with `systemd`, this creates a system unit with `User=` set — it requires root permission (via sudo) to schedule, but the backup itself runs as the unprivileged user. If you want to schedule without sudo, use `user_logged_on` with [lingering](https://wiki.archlinux.org/title/Systemd/User#Automatic_start-up_of_systemd_user_instances) enabled instead.
 
-* `user_logged_on`: **Not for crond** - Provides the same permissions as `user`, but runs only when the user is logged on. On Windows, it does not ask for your user password.
+* `user_logged_on`: **Not for crond** - Provides the same permissions as `user`, but runs only when the user is logged on (unless [lingering](https://wiki.archlinux.org/title/Systemd/User#Automatic_start-up_of_systemd_user_instances) is enabled). On Linux with `systemd`, this creates a unit in the user's systemd profile (`~/.config/systemd/user/`) and does **not** require sudo to schedule. On Windows, it does not ask for your user password.
 
 * *empty*: resticprofile will guess based on how it was started (with sudo or as a normal user). The fallback is `system` on Windows and `user_logged_on` on other platforms.
 

docs/content/schedules/systemd.md

@@ -6,9 +6,13 @@ weight: 105
 
 **systemd** is a common service manager used by many Linux distributions. resticprofile can create systemd timer and service files.
 
-User systemd units are created under the user's systemd profile (`~/.config/systemd/user`).
+The type of unit created depends on the `schedule-permission` setting:
 
-System units are created in `/etc/systemd/system`.
+| Permission         | Unit location                  |
+|--------------------|-------------------------------|
+| `system`           | `/etc/systemd/system/`        |
+| `user`             | `/etc/systemd/system/` (with `User=` field set) |
+| `user_logged_on`   | `~/.config/systemd/user/`     |
 
 ## systemd calendars
 
@@ -57,11 +61,19 @@ Until version v0.30.0, the `user` permission was actually `user_logged_on` unles
 
 This is now fixed:
 
-| Permission         | Type of unit                              | Without lingering                | With lingering      |
-|--------------------|-------------------------------------------|----------------------------------|---------------------|
-| **system**         | system service                            | can run any time                 | can run any time    |
-| **user**           | system service with User= field defined   | can run any time                 | can run any time    |
-| **user_logged_on** | user service                              | runs only when user is logged on | can run any time    |
+| Permission         | Type of unit                              | Without lingering                | With lingering      | Requires sudo to schedule |
+|--------------------|-------------------------------------------|----------------------------------|---------------------|---------------------------|
+| **system**         | system service                            | can run any time                 | can run any time    | yes                       |
+| **user**           | system service with User= field defined   | can run any time                 | can run any time    | yes                       |
+| **user_logged_on** | user service                              | runs only when user is logged on | can run any time    | no                        |
+
+{{% notice tip %}}
+If you want to run backups as a regular user without root privileges at scheduling time, use `permission: user_logged_on`. To allow the schedule to run even when the user is not logged in, enable [lingering](https://wiki.archlinux.org/title/Systemd/User#Automatic_start-up_of_systemd_user_instances) for your user:
+
+```shell
+loginctl enable-linger $USER
+```
+{{% /notice %}}