On macos, version 4.0.3, podman machine init --rootful does not respect --runroot

[robbiemu]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

On macos, version 4.0.3, podman machine init --rootful does not respect --runroot dir set in /etc/containers/containers.conf

Steps to reproduce the issue:

1. create a containers.conf like:

runroot = "/var/run/containers/storage"

or

[containers]
runroot = "/var/run/containers/storage"

[engine]
runroot = "/var/run/containers/storage"

[machine]
runroot = "/var/run/containers/storage"

[network]
runroot = "/var/run/containers/storage"

[secrets]
runroot = "/var/run/containers/storage"

[configmaps]
runroot = "/var/run/containers/storage"

2. build any rootful like:

sudo podman machine init --cpus 4 \
            --disk-size 128 \
            --memory 8196 \
            --rootful \
            --volume /Users/Shared/volumes/podman:/mnt/shared \
            podman-vm

Describe the results you received:

Error: mkdir /run: read-only file system

This directory does not exist in MacOS, instead it is /var/run

Describe the results you expected:

Successful creation and deployment from /var/run instead of $HOME/.local/run/user/$UID/run

Output of podman version:
(run having created the instance in my local directory)

Client:       Podman Engine
Version:      4.0.3
API Version:  4.0.3
Go Version:   go1.18
Built:        Fri Apr  1 11:28:59 2022
OS/Arch:      darwin/arm64

Server:       Podman Engine
Version:      4.0.2
API Version:  4.0.2
Go Version:   go1.16.14
Built:        Thu Mar  3 09:58:50 2022
OS/Arch:      linux/arm64

Output of podman info --debug:
(run having created the instance in my local directory)

host:
  arch: arm64
  buildahVersion: 1.24.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - pids
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.0-2.fc35.aarch64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.0, commit: '
  cpus: 4
  distribution:
    distribution: fedora
    variant: coreos
    version: "35"
  eventLogger: journald
  hostname: localhost.localdomain
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.15.18-200.fc35.aarch64
  linkmode: dynamic
  logDriver: journald
  memFree: 7564013568
  memTotal: 8301731840
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.4.2-1.fc35.aarch64
    path: /usr/bin/crun
    version: |-
      crun version 1.4.2
      commit: f6fbc8f840df1a414f31a60953ae514fa497c748
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.12-2.fc35.aarch64
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 3m 10.32s
plugins:
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 0
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.0.2
  Built: 1646319530
  BuiltTime: Thu Mar  3 09:58:50 2022
  GitCommit: ""
  GoVersion: go1.16.14
  OsArch: linux/arm64
  Version: 4.0.2

Package info (e.g. output of rpm -q podman or apt list podman):

brew info podman

remove@srvmini2 ~ % brew info podman
podman: stable 4.0.3 (bottled), HEAD
Tool for managing OCI containers and pods
https://podman.io/
/opt/homebrew/Cellar/podman/4.0.3 (172 files, 46.2MB) *
  Poured from bottle on 2022-04-08 at 09:40:42
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/podman.rb
License: Apache-2.0
==> Dependencies
Build: go ✘, go-md2man ✘
Required: qemu ✔
==> Options
--HEAD
	Install HEAD version
==> Caveats
zsh completions have been installed to:
  /opt/homebrew/share/zsh/site-functions
==> Analytics
install: 23,422 (30 days), 49,677 (90 days), 121,758 (365 days)
install-on-request: 23,417 (30 days), 49,661 (90 days), 121,734 (365 days)
build-error: 8 (30 days)
remove@srvmini2 ~ % 

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

MacOS on arm64.

if I get rid of the sudo and then start the client, it exists, but it is not created rootfully (in terms of file locations):

INFO[0000] waiting for clients...                       
INFO[0000] new connection from  to /var/folders/zl/llm51l2x0355lk6lpxvyhmyw0000gp/T/podman/qemu_podman-vm.sock 
Waiting for VM ...
INFO[0027] Socket forward established: /Users/remove/.local/share/containers/podman/machine/podman-vm/podman.sock to /run/podman/podman.sock 
Mounting volume... /Users/Shared/volumes/podman:/mnt/shared
API forwarding listening on: /var/run/docker.sock
Docker API clients default to this address. You do not need to set DOCKER_HOST.

Machine "podman-vm" started successfully

[Luap99]

What are you trying to do? Why do you run podman machine as root? Have you tried just running it rootless?

runroot is not an option in containers.conf it must be set in storage.conf. However this setting is only applicable for inside the VM, it will not be used on your mac.

[robbiemu]

thanks for the clarity at the end there.

I am trying to run podman as a service and .. I think I have that actually, (wrote the plist for it and put it in /Libvrary/LaunchDaemons). The only thing is that the initial install happens in the user directly .. so all the device links, storage, etc, are pointing to locations related to that user account.

Dont really want it pointing to root, I just want it to not be associated with a user.

[rhatdan]

This should be a discussion not an issue.

[holly-cummins]

Would adding

    <key>UserName</key>
    <string>youruser</string>

to the plist file help? (For what it's worth, I'm doing that now and it starts the service, then immediately stops it, so I have a different problem, but the user is right.)