podman: podman run fails if `--tty` or `-t` is used and `/tmp` is mapped to the podman machine

Issue Description

After reporting this issue, I tested with a default podman machine. In that case, the issue described below does NOT occur.

I do run into the issue when using a freshly created machine close to the default machine but with an extra mapping to /tmp:

podman machine init \
  -v /Users:/Users \                        # <--- default
  -v /private:/private \                    # <--- default
  -v /var/folders:/var/folders \            # <--- default
  -v /tmp:/tmp                              # <--- non default and breaking

Mapping /private/tmp does work fine though.

what works

$ podman run ubuntu echo "Hello"

Resolved "ubuntu" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/ubuntu:latest...
Getting image source signatures
Copying blob sha256:2ab09b027e7f3a0c2e8bb1944ac46de38cebab7145f0bd6effebfe5492c818b6
Copying config sha256:08d22c0ceb150ddeb2237c5fa3129c0183f3cc6f5eeb2e7aa4016da3ad02140a
Writing manifest to image destination
Storing signatures
Hello

what does not work

$ podman run -t ubuntu echo "Hello"

Error: preparing container 873a0d7c4f7137d12b4ec1a3dc51c9021769e444e944bef8b542af3a2050d6da for attach: container create failed (no logs from conmon): conmon bytes "": readObjectStart: expect { or n, but found , error found in #0 byte of ...||..., bigger context ...||...

Steps to reproduce the issue

podman run -t ubuntu echo "Hello"

or

podman run -it ubuntu

Describe the results you received

See description

Describe the results you expected

Using --tty or -t works without error.

podman info output

host:
  arch: amd64
  buildahVersion: 1.29.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.7-2.fc37.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.7, commit: '
  cpuUtilization:
    idlePercent: 99.31
    systemPercent: 0.44
    userPercent: 0.25
  cpus: 4
  distribution:
    distribution: fedora
    variant: coreos
    version: "37"
  eventLogger: journald
  hostname: localhost.localdomain
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 1000000
    uidmap:
    - container_id: 0
      host_id: 501
      size: 1
    - container_id: 1
      host_id: 100000
      size: 1000000
  kernel: 6.2.8-200.fc37.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 32253423616
  memTotal: 32849166336
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.8.3-2.fc37.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.3
      commit: 59f2beb7efb0d35611d5818fd0311883676f6f7e
      rundir: /run/user/501/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/501/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
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-8.fc37.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 0h 11m 38.00s
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /var/home/core/.config/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 0
    stopped: 3
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/core/.local/share/containers/storage
  graphRootAllocated: 106769133568
  graphRootUsed: 2748747776
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 2
  runRoot: /run/user/501/containers
  transientStore: false
  volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
  APIVersion: 4.4.2
  Built: 1677669779
  BuiltTime: Wed Mar  1 12:22:59 2023
  GitCommit: ""
  GoVersion: go1.19.6
  Os: linux
  OsArch: linux/amd64
  Version: 4.4.2

Podman in a container

No

Privileged Or Rootless

Tried both, appears not relevant.

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Comments: 15 (4 by maintainers)

Most upvoted comments

Mapping /private/tmp does work fine though.

Are you using -v /private/tmp:/tmp or -v /private/tmp:/private/tmp, then?

The latter probably indicates nothing either way.

if the former works, and the two behave differently, that would suggest that we are mapping just the symlink over 9pfs. And in that case we are creating a socket inside the VM at /private/tmp/…, and I can well imagine permissions, or SELinux, not being happy with that.


Does 9p filesystem mount support sockets?

https://github.com/torvalds/linux/blob/2d1bcbc6cd703e64caf8df314e3669b4786e008a/fs/9p/vfs_inode.c#L54-L55 suggests that it can, depending on options (and server support?).

If I had to guess, it would be related to logging - trying a container with --log-driver=none will probably confirm that.

As the reporter shows it only fails with --tty logging should be the same regardless of --tty set or not.

Following the code in conmon I found this: https://github.com/containers/conmon/blob/08c34bda8c75a37f153dfbd63399d22050551053/src/conn_sock.c#L170-L191

get_tmp_dir defaults to /tmp so conmon tries to create to create a temporary socket under /tmp. https://docs.gtk.org/glib/func.get_tmp_dir.html

Does 9p filesystem mount support sockets? I think the socket call is failing but then I still do not understand why there is no error message from conmon in the journal.