You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unable to start a container after volume export / import because of incorrect ownership and permissions on the root of the volume mount path.
The volume was mounted to /var/lib/postgresql/14/main and postgres would not start because /var/lib/postgresql/14/main was owned by root:root. I had to do podman unshare then manually change the owner and permissions of the ~/.local/share/containers/storage/volumes/foo/_data directory to get the container to work.
Steps to reproduce the issue
Steps to reproduce the issue
podman volume export foo -o foo.tar
podman system reset
podman volume create foo
podman volume import foo foo.tar
Describe the results you received
The root directory of the volume ( or "_data" on local fs) has the default permissions of 755 and is owned by "myuser:myuser" outside the container and "root:root" inside the container, regardless of the original owner and permissions.
Describe the results you expected
I expected everything to be preserved through the export / import process.
podman info output
host:
arch: amd64buildahVersion: 1.38.1cgroupControllers:
- memory
- pidscgroupManager: systemdcgroupVersion: v2conmon:
package: conmon-2.1.12-1.el9.x86_64path: /usr/bin/conmonversion: 'conmon version 2.1.12, commit: 5859d6167f22954414ce804d3f2ae9cf6208f929'cpuUtilization:
idlePercent: 99.47systemPercent: 0.22userPercent: 0.31cpus: 4databaseBackend: sqlitedistribution:
distribution: rockyversion: "9.5"eventLogger: journaldfreeLocks: 2042hostname: borg.plinidMappings:
gidmap:
- container_id: 0host_id: 3005size: 1
- container_id: 1host_id: 624288size: 65536uidmap:
- container_id: 0host_id: 3003size: 1
- container_id: 1host_id: 624288size: 65536kernel: 5.14.0-503.23.2.el9_5.x86_64linkmode: dynamiclogDriver: journaldmemFree: 237125632memTotal: 12272603136networkBackend: netavarknetworkBackendInfo:
backend: netavarkdns:
package: aardvark-dns-1.13.1-1.el9.x86_64path: /usr/libexec/podman/aardvark-dnsversion: aardvark-dns 1.13.1package: netavark-1.13.1-1.el9.x86_64path: /usr/libexec/podman/netavarkversion: netavark 1.13.1ociRuntime:
name: /usr/bin/crunpackage: crun-1.19.1-1.el9.x86_64path: /usr/bin/crunversion: |- crun version 1.19.1 commit: 3e32a70c93f5aa5fea69b50256cca7fd4aa23c80 rundir: /run/user/3003/crun spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJLos: linuxpasta:
executable: /usr/bin/pastapackage: passt-0^20250121.g4f2c8e7-3.el9.x86_64version: | pasta 0^20250121.g4f2c8e7-3.el9.x86_64 Copyright Red Hat GNU General Public License, version 2 or later <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.remoteSocket:
exists: truepath: /run/user/3003/podman/podman.sockrootlessNetworkCmd: pastasecurity:
apparmorEnabled: falsecapabilities: 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_CHROOTrootless: trueseccompEnabled: trueseccompProfilePath: /usr/share/containers/seccomp.jsonselinuxEnabled: falseserviceIsRemote: falseslirp4netns:
executable: /usr/bin/slirp4netnspackage: slirp4netns-1.3.1-1.el9.x86_64version: |- slirp4netns version 1.3.1 commit: e5e368c4f5db6ae75c2fce786e31eef9da6bf236 libslirp: 4.4.0 SLIRP_CONFIG_VERSION_MAX: 3 libseccomp: 2.5.2swapFree: 12883312640swapTotal: 12883849216uptime: 33h 7m 53.00s (Approximately 1.38 days)variant: ""plugins:
authorization: nulllog:
- k8s-file
- none
- passthrough
- journaldnetwork:
- bridge
- macvlan
- ipvlanvolume:
- localregistries:
search:
- docker.iostore:
configFile: /opt/traccar/.config/containers/storage.confcontainerStore:
number: 3paused: 0running: 3stopped: 0graphDriverName: overlaygraphOptions: {}graphRoot: /opt/traccar/.local/share/containers/storagegraphRootAllocated: 407867219968graphRootUsed: 66529746944graphStatus:
Backing Filesystem: extfsNative Overlay Diff: "true"Supports d_type: "true"Supports shifting: "false"Supports volatile: "true"Using metacopy: "false"imageCopyTmpDir: /var/tmpimageStore:
number: 4runRoot: /run/user/3003/containerstransientStore: falsevolumePath: /opt/traccar/.local/share/containers/storage/volumesversion:
APIVersion: 5.3.2Built: 1738675282BuiltTime: Tue Feb 4 14:21:22 2025GitCommit: ""GoVersion: go1.23.4 (Red Hat 1.23.4-1.el9)Os: linuxOsArch: linux/amd64Version: 5.3.2
Podman in a container
No
Privileged Or Rootless
Rootless
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
The text was updated successfully, but these errors were encountered:
I think what's happening here is the usual chown/permission adjustment that would happen with the volume on being mounted into a container isn't happening because the volume is not empty. Can you include an ls -al of /var/lib/postgresql/14/main on a container with an empty volume mounted to it, and on a container with the volume with imported contents mounted to it?
Issue Description
Unable to start a container after volume export / import because of incorrect ownership and permissions on the root of the volume mount path.
The volume was mounted to
/var/lib/postgresql/14/main
and postgres would not start because/var/lib/postgresql/14/main
was owned byroot:root
. I had to dopodman unshare
then manually change the owner and permissions of the~/.local/share/containers/storage/volumes/foo/_data
directory to get the container to work.Steps to reproduce the issue
Steps to reproduce the issue
Describe the results you received
The root directory of the volume ( or "_data" on local fs) has the default permissions of 755 and is owned by "myuser:myuser" outside the container and "root:root" inside the container, regardless of the original owner and permissions.
Describe the results you expected
I expected everything to be preserved through the export / import process.
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
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
The text was updated successfully, but these errors were encountered: