Volume mount disappearing, requires machine be restarted

[JDUNNIN]

Issue Description

1. I initialise a podman machine using podman machine init --rootful --memory 8192 --cpus 4 .
2. I start the machine and see it successfully mounts my home directory.
3. I use podman machine ssh to connect and issue ls /Users/myUser and see all my files and folders correctly mounted.
4. Some time later I am running tests and hit a statfs error suggesting the directory I'm trying to mount is not available.
5. I use podman machine ssh to connect and issue ls /Users/myUser and see that only the single mounted directory is present (but importantly is empty) or I the whole /Users/myUser` dir is missing.

I get the feeling this could be to do with sleeping the laptop breaking mounts as often hit this in the morning. It may occur other times as well, unsure.

To resolve I have to stop and start the podman machine.

Steps to reproduce the issue

Steps to reproduce the issue

1. Use podman machine with mounts
2. ? Potentially sleep laptop a series of times each time checking podman machine ssh to ls /Users/myUser dir contents.

Describe the results you received

Volume mount lost in podman machine.

Describe the results you expected

Mount is consistent

podman info output

podman info                                                        
host:
  arch: amd64
  buildahVersion: 1.30.0
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.7-2.fc38.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.7, commit: '
  cpuUtilization:
    idlePercent: 95.81
    systemPercent: 2.26
    userPercent: 1.92
  cpus: 4
  databaseBackend: boltdb
  distribution:
    distribution: fedora
    variant: coreos
    version: "38"
  eventLogger: journald
  hostname: localhost.localdomain
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.3.11-200.fc38.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 6595563520
  memTotal: 8312438784
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.8.5-1.fc38.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.5
      commit: b6f80f766c9a89eb7b1440c0a70ab287434b17ed
      rundir: /run/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +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.2.0-12.fc38.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: 4h 33m 44.00s (Approximately 0.17 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /usr/share/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
  graphRootAllocated: 106769133568
  graphRootUsed: 8235008000
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 212
  runRoot: /run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.5.1
  Built: 1685123928
  BuiltTime: Fri May 26 18:58:48 2023
  GitCommit: ""
  GoVersion: go1.20.4
  Os: linux
  OsArch: linux/amd64
  Version: 4.5.1

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

macOS x86.

Additional information

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

[Luap99]

Does the the sleep cause a reboot in the machine? This could be the same problem as #15976

[JDUNNIN]

I did see that issue but I wasn't issuing any commands so raised this too - it could well be related / the same cause. If you're happy that it is the same thing then no problem closing this as duplicate, just wanted to raise it for awareness 👍

[Luap99]

Can you compare uptime in the VM with LAST UP from podman machine ls the next time it happens to you.
Then we know if the VM got rebooted without podman machine knowing.

[JDUNNIN]

@Luap99 Good idea, will do!

[JDUNNIN]

@Luap99 fairly certain I started podman machine yesterday and yet uptime only shows 7 hours ago, roughly when I opened laptop again today. For me LAST UP doesn't give an uptime instead just Currently running and can't see a time anywhere else for it. But from the uptime it looks like it thinks it started later than it really did.

[Luap99]

Try podman machine inspect that should display the actual time I think. But yeah sounds like #15976 then

[JDUNNIN]

I agree - happy if this is closed as dup.

[Luap99]

Duplicate of #15976