"user" schedule permission instead of "system" not working as anticipated

[l1a]

Hello all, hopefully this isn't a repeat but I couldn't find the answer here or anywhere on the InterWebs.

I'm trying to schedule a job via systemd in user space.

On Fedora 42, when i try to schedule a profile using this (cleaned up) config file:

# yaml-language-server: $schema=https://creativeprojects.github.io/resticprofile/jsonschema/config.json

version: "2"

global:
  # ionice is available on Linux only
  ionice: true
  ionice-class: 2
  ionice-level: 6
  # priority is using priority class on windows, and "nice" on unixes
  priority: low
  # run 'snapshots' when no command is specified when invoking resticprofile
  default-command: "snapshots"
  # initialize a repository if none exist at location
  initialize: false
  # resticprofile won't start a profile if there's less than 100MB of RAM available
  min-memory: 500
  # prevent sleep (doesn't work on batteries)
  # Logging
  # log: "-"
  # schedule defaults
  schedule-defaults:
    log: "{{ .ConfigDir }}/logs/scheduled-{{ .Profile.Name }}.log"
    # permission: "user"
    lock-wait: "10m"
    lock-mode: default
    priority: background
    # ignore-on-battery: true
    # after-network-online: true

# All individual backup configurations are now nested under this 'profiles' section
profiles:
  # Default profile when not specified on the command line (-n or --name)
  # There's no default inheritance from the 'default' profile,
  # you can use the 'inherit' flag if needed
  default:
    # Google Cloud Storage config
    gcs:
      project-id: "my-gcs-project-0123456789"
      credentials-file: "/path/to/secrets/gcs-token.json"
      connections: 10
    initialize: false
    schedule:
      # permission: user
      priority: background

  # Backup various ".*" files from home directory
  dot-test:
    inherit: "default"
    initialize: true
    priority: background
    repository: "gs:foo-backup-01:/dot-test"
    password-file: "/path/to/secrets/file.pw.txt"
    # 'backup' command
    backup:
      # Start in our home directory
      source-base: "{{ .Env.HOME }}"
      source-relative: true
      source:
        - ".config"
        - ".local/share"
      # A list of files or directories to exclude from the backup.
      exclude:
        - "/**/.git"
        - ".cache"
        - ".gradle/caches"
        - ".m2/repository"
        - ".local/share/Trash"
        - "**/node_modules"
        - "**/.DS_Store"
        - "**/*.pyc"
      exclude-caches: true
      one-file-system: false
      tag:
        - "{{ .Profile.Name }}"
        - "{{ .Hostname }}"
        - "{{ .OS }}"
        - "{{ .Arch }}"
      check-before: false
      schedule:
        at: daily
        permission: user
        after-network-online: true
        priority: background
    # retention policy
    retention:
      before-backup: false
      after-backup: true
      keep-daily: 7
      keep-weekly: 4
      keep-monthly: 12
      keep-yearly: 2
      prune: true
    forget:
      keep-daily: 7
      keep-weekly: 4
      keep-monthly: 12
      keep-yearly: 2
      prune: true
      # This groups snapshots by both hostname and the source path before applying the policy.
      group-by: "host,paths"`

The result is as follows:

❯ resticprofile --config test.yaml dot-test.show
global:
    ionice:                   true
    ionice-class:             2
    ionice-level:             6
    priority:                 low
    default-command:          snapshots
    restic-arguments-filter:  true
    restic-lock-retry-after:  1m0s
    restic-stale-lock-age:    1h0m0s
    min-memory:               500

    schedule-defaults:
        log:        /home/ktobias/.config/resticprofile/logs/scheduled-default.log
        priority:   background
        lock-mode:  default
        lock-wait:  10m0s

    command-output:  auto
    send-timeout:    30s

profile dot-test:
    gcs:                     connections:10
                             credentials-file:/path/to/secrets/gcs-token.json
                             project-id:my-gcs-project-0123456789
    priority:                background
    schedule:                priority:background
    repository:              gs:foo-backup-01:/dot-test
    password-file:           /path/to/secrets/file.pw.txt
    initialize:              true
    prometheus-push-format:  text

    backup:
        exclude-caches:   true
        host:             true
        tag:              dot-test
                          irulan
                          linux
                          amd64
        source-relative:  true
        source-base:      /home/ktobias
        source:           .config
                          .local/share
        exclude:          /**/.git
                          .cache
                          .gradle/caches
                          .m2/repository
                          .local/share/Trash
                          **/node_modules
                          **/.DS_Store
                          **/*.pyc

    retention:
        host:           true
        keep-daily:     7
        keep-monthly:   12
        keep-weekly:    4
        keep-yearly:    2
        path:           /home/ktobias/.config
                        /home/ktobias/.local/share
        prune:          true
        tag:            dot-test,irulan,linux,amd64
        before-backup:  false
        after-backup:   true

    forget:
        group-by:      host,paths
        keep-daily:    7
        keep-monthly:  12
        keep-weekly:   4
        keep-yearly:   2
        prune:         true

schedule backup@dot-test:
    at:                    daily
    permission:            user
    log:                   /home/ktobias/.config/resticprofile/logs/scheduled-dot-test.log
    priority:              background
    lock-mode:             default
    lock-wait:             10m0s
    after-network-online:  true

❯ resticprofile --config test.yaml dot-test.schedule
2025/08/23 12:51:18 error creating job dot-test/backup: user is not allowed to create a system job: please restart resticprofile as root (with sudo)

The "show" method clearly shows it's parsing. If I introduce syntax errors, "show" complains.

• I've tried putting the "permission" statement in various places like "global", "default", "backup".
• I've tried using the "schedule-permission" form in all of the above places.
• I've tried using TOML with all of the same variations.
• I've tried using v1 config file format (i.e. without the wrapping "profile" section).
• The schema is referenced at the top of the config and both Zed and Code pass lint.
• I've tried using a local backup repository instead of gcs.
• I've tried removing the "after-network-online" statement.
• This same file will schedule just fine on MacOS.
• The backup section works just fine when run manually.

Just for reference on version numbers and such:

❯ resticprofile --verbose
2025/08/23 13:23:29 resticprofile 0.31.0 compiled with go1.24.3
2025/08/23 13:23:29 using configuration file: profiles.yaml
2025/08/23 13:23:29 loading: profiles.yaml
2025/08/23 13:23:29 memory available: 20459MB
2025/08/23 13:23:29 setting process group priority to 10
2025/08/23 13:23:29 setting IO priority class to 2, level 6
2025/08/23 13:23:29 using restic 0.18.0
2025/08/23 13:23:29 profile 'default': starting 'snapshots'
2025/08/23 13:23:29 command environment: reusing previous
2025/08/23 13:23:29 starting command: /usr/bin/restic snapshots --verbose=1
Fatal: Please specify repository location (-r or --repository-file)
2025/08/23 13:23:29 snapshots on profile 'default': exit status 1

I'm stumped. What am I missing?

Thanks in advance for any help.

[l1a]

So after a great deal of AI thrashing (as an aside, only Grok was able to answer this for me), I have figured out that the "user" permission in resticprofile doesn't actually create a user level systemd job. It creates a system level job that runs as the user. The only way to actually run a user level job is to use "user_logged_on" permission.

Why did we make this choice? To avoid "linger" permission for the user? This seems counter intuitive and counter to the systemd intent for scheduling.

This leaves me with needing to sudo every scheduling task if I want to run restic in user space unless I only want the job to run while I'm logged in.

Thoughts?

[creativeprojects]

To avoid "linger" permission for the user?

This is the reason.

Basically I had two options:

1) we force the admin to set the linger option to the user

• any process from the user will be allowed to run when not logged on (you can't just set it for resticprofile).
• you still need to have access to sudo at least once to set it up.
• this is not something very well known (unless you're a true sysadmin)

2) we create a system service

• yes we do need sudo to set up the schedule (is it happening very often?)
• this is transparent for most users
• no need for reading documentation on obscure linger flag in systemd

But now, you can still set the linger on your user directly, and set the profile as user_logged_on:

• no more sudo
• it will run when the user isn't logged in

With this decision, we can get the best of both worlds 👍🏻

... except I totally forgot to mention all of that in the documentation 😆

[l1a]

This logic eludes me: - If you have to have sudo permission to update/create/remove jobs that run when you are not logged in, you already have sudo permission so you could set linger without much trouble. In fact, you have to have more permissions. You either have to have permanent full sudo permission or a smart sysadmin who can set you up with sudo permissions for just that command (which is possible). The only practical result is that you have to type "sudo" more often. - Some features don't seem to work right (e.g. $Env.HOME). I forked and changed the code to follow the systemd linger logic and things seem to work better. - Setting linger on the user and then using user_logged_on defeats the purpose of having the job run when not logged on. Furthermore, linger shouldn't be required when setting user_logged_on as then the job only runs when logged on. - If you use the user_logged_on setting and say set the cycle to daily, the job never runs unless you happen to be logged in at midnight. I think there is a way around this and have systemd catch up on jobs that haven't run but I haven't figured that out yet. Just my 2 cents.

…

On Thu, Aug 28, 2025 at 9:14 AM Fred ***@***.***> wrote: To avoid "linger" permission for the user? This is the reason. Basically I had two options: 1) we force the admin to set the linger option to the user - any process from the user will be allowed to run when not logged on (you can't just set it for resticprofile). - you still need to have access to sudo at least once to set it up. - this is not something very well known (unless you're a true sysadmin) 2) we create a system service - yes we do need sudo to set up the schedule (is it happening very often?) - this is transparent for most users - no need for reading documentation on obscure linger flag in systemd *But now, you can still set the linger on your user directly, and set the profile as user_logged_on:* - no more sudo - it will run when the user isn't logged in With this decision, we can the best of both worlds 👍🏻 ... except I totally forgot to mention all of that in the documentation 😆 — Reply to this email directly, view it on GitHub <#553 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE24DE5G6TR6UHWMF6HAQD3P4TGDAVCNFSM6AAAAACEURRWVWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRUG4ZDOOA> . You are receiving this because you authored the thread.Message ID: <creativeprojects/resticprofile/repo-discussions/553/comments/14247278@ github.com>