1podman-pod-create(1)() podman-pod-create(1)()
2
3
4
6 podman-pod-create - Create a new pod
7
8
10 podman pod create [options]
11
12
14 Creates an empty pod, or unit of multiple containers, and prepares it
15 to have containers added to it. The pod id is printed to STDOUT. You
16 can then use podman create --pod <pod_id|pod_name> ... to add contain‐
17 ers to the pod, and podman pod start <pod_id|pod_name> to start the
18 pod.
19
20
22 --add-host=host:ip
23 Add a custom host-to-IP mapping (host:ip)
24
25
26 Add a line to /etc/hosts. The format is hostname:ip. The --add-host op‐
27 tion can be set multiple times. The /etc/hosts file is shared between
28 all containers in the pod.
29
30
31 --cgroup-parent=path
32 Path to cgroups under which the cgroup for the pod will be created. If
33 the path is not absolute, the path is considered to be relative to the
34 cgroups path of the init process. Cgroups will be created if they do
35 not already exist.
36
37
38 --cpus=amount
39 Set the total number of CPUs delegated to the pod. Default is 0.000
40 which indicates that there is no limit on computation power.
41
42
43 --cpuset-cpus=amount
44 Limit the CPUs to support execution. First CPU is numbered 0. Unlike
45 --cpus this is of type string and parsed as a list of numbers
46
47
48 Format is 0-3,0,1
49
50
51 Examples of the List Format:
52
53
54 0-4,9 # bits 0, 1, 2, 3, 4, and 9 set 0-2,7,12-14 # bits
55 0, 1, 2, 7, 12, 13, and 14 set
56
57
58 --device=host-device[:container-device][:permissions]
59 Add a host device to the pod. Optional permissions parameter can be
60 used to specify device permissions. It is a combination of r for read,
61 w for write, and m for mknod(2).
62
63
64 Example: --device=/dev/sdc:/dev/xvdc:rwm.
65
66
67 Note: if _hostdevice is a symbolic link then it will be resolved first.
68 The pod will only store the major and minor numbers of the host device.
69
70
71 Note: the pod implements devices by storing the initial configuration
72 passed by the user and recreating the device on each container added to
73 the pod.
74
75
76 Podman may load kernel modules required for using the specified device.
77 The devices that Podman will load modules for when necessary are:
78 /dev/fuse.
79
80
81 --device-read-bps=path
82 Limit read rate (bytes per second) from a device (e.g. --device-read-
83 bps=/dev/sda:1mb)
84
85
86 --dns=ipaddr
87 Set custom DNS servers in the /etc/resolv.conf file that will be shared
88 between all containers in the pod. A special option, "none" is allowed
89 which disables creation of /etc/resolv.conf for the pod.
90
91
92 --dns-opt=option
93 Set custom DNS options in the /etc/resolv.conf file that will be shared
94 between all containers in the pod.
95
96
97 --dns-search=domain
98 Set custom DNS search domains in the /etc/resolv.conf file that will be
99 shared between all containers in the pod.
100
101
102 --gidmap=container_gid:host_gid:amount
103 GID map for the user namespace. Using this flag will run the container
104 with user namespace enabled. It conflicts with the --userns and --sub‐
105 gidname flags.
106
107
108 --help, -h
109 Print usage statement.
110
111
112 --hostname=name
113 Set a hostname to the pod
114
115
116 --infra
117 Create an infra container and associate it with the pod. An infra con‐
118 tainer is a lightweight container used to coordinate the shared kernel
119 namespace of a pod. Default: true.
120
121
122 --infra-command=command
123 The command that will be run to start the infra container. Default:
124 "/pause".
125
126
127 --infra-conmon-pidfile=file
128 Write the pid of the infra container's conmon process to a file. As
129 conmon runs in a separate process than Podman, this is necessary when
130 using systemd to manage Podman containers and pods.
131
132
133 --infra-image=image
134 The custom image that will be used for the infra container. Unless
135 specified, Podman builds a custom local image which does not require
136 pulling down an image.
137
138
139 --infra-name=name
140 The name that will be used for the pod's infra container.
141
142
143 --ip=ip
144 Specify a static IP address for the pod, for example 10.88.64.128.
145 This option can only be used if the pod is joined to only a single net‐
146 work - i.e., --network=network-name is used at most once - and if the
147 pod is not joining another container's network namespace via --net‐
148 work=container:id. The address must be within the network's IP address
149 pool (default 10.88.0.0/16).
150
151
152 To specify multiple static IP addresses per pod, set multiple networks
153 using the --network option with a static IP address specified for each
154 using the ip mode for that option.
155
156
157 --ip6=ipv6
158 Specify a static IPv6 address for the pod, for example
159 fd46:db93:aa76:ac37::10. This option can only be used if the pod is
160 joined to only a single network - i.e., --network=network-name is used
161 at most once - and if the pod is not joining another container's net‐
162 work namespace via --network=container:id. The address must be within
163 the network's IPv6 address pool.
164
165
166 To specify multiple static IPv6 addresses per pod, set multiple net‐
167 works using the --network option with a static IPv6 address specified
168 for each using the ip6 mode for that option.
169
170
171 --label=label, -l
172 Add metadata to a pod (e.g., --label com.example.key=value).
173
174
175 --label-file=label
176 Read in a line delimited file of labels.
177
178
179 --mac-address=address
180 Pod network interface MAC address (e.g. 92:d0:c6:0a:29:33) This option
181 can only be used if the pod is joined to only a single network - i.e.,
182 --network=network-name is used at most once - and if the pod is not
183 joining another container's network namespace via --network=con‐
184 tainer:id.
185
186
187 Remember that the MAC address in an Ethernet network must be unique.
188 The IPv6 link-local address will be based on the device's MAC address
189 according to RFC4862.
190
191
192 To specify multiple static MAC addresses per pod, set multiple networks
193 using the --network option with a static MAC address specified for each
194 using the mac mode for that option.
195
196
197 --name=name, -n
198 Assign a name to the pod.
199
200
201 --network=mode, --net
202 Set the network mode for the pod. Invalid if using --dns, --dns-opt, or
203 --dns-search with --network that is set to none or container:id.
204
205
206 Valid mode values are:
207
208
209 • bridge[:OPTIONS,...]: Create a network stack on the default
210 bridge. This is the default for rootful containers. It is pos‐
211 sible to specify these additional options:
212
213 • alias=name: Add network-scoped alias for the container.
214
215 • ip=IPv4: Specify a static ipv4 address for this container.
216
217 • ip=IPv6: Specify a static ipv6 address for this container.
218
219 • mac=MAC: Specify a static mac address for this container.
220
221 • interface_name: Specify a name for the created network in‐
222 terface inside the container.
223
224
225
226
227
228 For example to set a static ipv4 address and a static mac address, use
229 --network bridge:ip=10.88.0.10,mac=44:33:22:11:00:99. - <network name
230 or ID>[:OPTIONS,...]: Connect to a user-defined network; this is the
231 network name or ID from a network created by podman network create. Us‐
232 ing the network name implies the bridge network mode. It is possible to
233 specify the same options described under the bridge mode above. You can
234 use the --network option multiple times to specify additional networks.
235 - none: Create a network namespace for the container but do not config‐
236 ure network interfaces for it, thus the container has no network con‐
237 nectivity. - container:id: Reuse another container's network stack. -
238 host: Do not create a network namespace, the container will use the
239 host's network. Note: The host mode gives the container full access to
240 local system services such as D-bus and is therefore considered inse‐
241 cure. - ns:path: Path to a network namespace to join. - private: Cre‐
242 ate a new namespace for the container. This will use the bridge mode
243 for rootful containers and slirp4netns for rootless ones. -
244 slirp4netns[:OPTIONS,...]: use slirp4netns(1) to create a user network
245 stack. This is the default for rootless containers. It is possible to
246 specify these additional options, they can also be set with net‐
247 work_cmd_options in containers.conf:
248 - allow_host_loopback=true|false: Allow the slirp4netns to reach the
249 host loopback IP (10.0.2.2). Default is false.
250 - mtu=MTU: Specify the MTU to use for this network. (Default is
251 65520).
252 - cidr=CIDR: Specify ip range to use for this network. (Default is
253 10.0.2.0/24).
254 - enable_ipv6=true|false: Enable IPv6. Default is true. (Required for
255 outbound_addr6).
256 - outbound_addr=INTERFACE: Specify the outbound interface slirp
257 should bind to (ipv4 traffic only).
258 - outbound_addr=IPv4: Specify the outbound ipv4 address slirp should
259 bind to.
260 - outbound_addr6=INTERFACE: Specify the outbound interface slirp
261 should bind to (ipv6 traffic only).
262 - outbound_addr6=IPv6: Specify the outbound ipv6 address slirp should
263 bind to.
264 - port_handler=rootlesskit: Use rootlesskit for port forwarding. De‐
265 fault.
266 Note: Rootlesskit changes the source IP address of incoming packets
267 to an IP address in the container network namespace, usually
268 10.0.2.100. If your application requires the real source IP address,
269 e.g. web server logs, use the slirp4netns port handler. The rootlesskit
270 port handler is also used for rootless containers when connected to
271 user-defined networks.
272 - port_handler=slirp4netns: Use the slirp4netns port forwarding, it
273 is slower than rootlesskit but preserves the correct source IP address.
274 This port handler cannot be used for user-defined networks.
275
276
277 --network-alias=alias
278 Add a network-scoped alias for the pod, setting the alias for all net‐
279 works that the pod joins. To set a name only for a specific network,
280 use the alias option as described under the --network option. Network
281 aliases work only with the bridge networking mode. This option can be
282 specified multiple times. NOTE: A container will only have access to
283 aliases on the first network that it joins. This is a limitation that
284 will be removed in a later release.
285
286
287 --no-hosts
288 Do not create /etc/hosts for the pod. By default, Podman will manage
289 /etc/hosts, adding the container's own IP address and any hosts from
290 --add-host. --no-hosts disables this, and the image's /etc/hosts will
291 be preserved unmodified. This option conflicts with --add-host.
292
293
294 --pid=pid
295 Set the PID mode for the pod. The default is to create a private PID
296 namespace for the pod. Requires the PID namespace to be shared via
297 --share.
298
299
300 host: use the host’s PID namespace for the pod
301 ns: join the specified PID namespace
302 private: create a new namespace for the pod (default)
303
304
305
306 --pod-id-file=path
307 Write the pod ID to the file.
308
309
310 --publish, -p=[[ip:][hostPort]:]containerPort[/protocol]
311 Publish a container's port, or range of ports, within this pod to the
312 host.
313
314
315 Both hostPort and containerPort can be specified as a range of ports.
316 When specifying ranges for both, the number of container ports in the
317 range must match the number of host ports in the range.
318
319
320 If host IP is set to 0.0.0.0 or not set at all, the port will be bound
321 on all IPs on the host.
322
323
324 By default, Podman will publish TCP ports. To publish a UDP port in‐
325 stead, give udp as protocol. To publish both TCP and UDP ports, set
326 --publish twice, with tcp, and udp as protocols respectively. Rootful
327 containers can also publish ports using the sctp protocol.
328
329
330 Host port does not have to be specified (e.g. podman run -p
331 127.0.0.1::80). If it is not, the container port will be randomly as‐
332 signed a port on the host.
333
334
335 Use podman port to see the actual mapping: podman port $CONTAINER $CON‐
336 TAINERPORT.
337
338
339 Note: You must not publish ports of containers in the pod individually,
340 but only by the pod itself.
341
342
343 Note: This cannot be modified once the pod is created.
344
345
346 --replace
347 If another pod with the same name already exists, replace and remove
348 it. The default is false.
349
350
351 --security-opt=option
352 Security Options
353
354
355 • apparmor=unconfined : Turn off apparmor confinement for the
356 pod
357
358 • apparmor=your-profile : Set the apparmor confinement profile
359 for the pod
360
361 • label=user:USER : Set the label user for the pod processes
362
363 • label=role:ROLE : Set the label role for the pod processes
364
365 • label=type:TYPE : Set the label process type for the pod
366 processes
367
368 • label=level:LEVEL : Set the label level for the pod pro‐
369 cesses
370
371 • label=filetype:TYPE : Set the label file type for the pod
372 files
373
374 • label=disable : Turn off label separation for the pod
375
376
377
378 Note: Labeling can be disabled for all pods/containers by setting la‐
379 bel=false in the containers.conf (/etc/containers/containers.conf or
380 $HOME/.config/containers/containers.conf) file.
381
382
383 • mask=/path/1:/path/2 : The paths to mask separated by a colon.
384 A masked path cannot be accessed inside the containers within
385 the pod.
386
387 • no-new-privileges : Disable container processes from gaining
388 additional privileges
389
390 • seccomp=unconfined : Turn off seccomp confinement for the pod
391
392 • seccomp=profile.json : Whitelisted syscalls seccomp Json file
393 to be used as a seccomp filter
394
395 • proc-opts=OPTIONS : Comma-separated list of options to use for
396 the /proc mount. More details for the possible mount options
397 are specified in the proc(5) man page.
398
399 • unmask=ALL or /path/1:/path/2, or shell expanded paths
400 (/proc/*): Paths to unmask separated by a colon. If set to
401 ALL, it will unmask all the paths that are masked or made read
402 only by default. The default masked paths are /proc/acpi,
403 /proc/kcore, /proc/keys, /proc/latency_stats, /proc/sched_de‐
404 bug, /proc/scsi, /proc/timer_list, /proc/timer_stats,
405 /sys/firmware, and /sys/fs/selinux. The default paths that
406 are read only are /proc/asound, /proc/bus, /proc/fs,
407 /proc/irq, /proc/sys, /proc/sysrq-trigger, /sys/fs/cgroup.
408
409
410
411 Note: Labeling can be disabled for all containers by setting la‐
412 bel=false in the containers.conf (/etc/containers/containers.conf or
413 $HOME/.config/containers/containers.conf) file.
414
415
416 --share=namespace
417 A comma-separated list of kernel namespaces to share. If none or "" is
418 specified, no namespaces will be shared. The namespaces to choose from
419 are cgroup, ipc, net, pid, uts.
420
421
422 The operator can identify a pod in three ways: UUID long identifier
423 (“f78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778”)
424 UUID short identifier (“f78375b1c487”) Name (“jonah”)
425
426
427 podman generates a UUID for each pod, and if a name is not assigned to
428 the container with --name then a random string name will be generated
429 for it. The name is useful any place you need to identify a pod.
430
431
432 --share-parent
433 This boolean determines whether or not all containers entering the pod
434 will use the pod as their cgroup parent. The default value of this flag
435 is true. If you are looking to share the cgroup namespace rather than a
436 cgroup parent in a pod, use --share
437
438
439 Note: This options conflict with --share=cgroup since that would set
440 the pod as the cgroup parent but enter the container into the same
441 cgroupNS as the infra container.
442
443
444 --subgidname=name
445 Name for GID map from the /etc/subgid file. Using this flag will run
446 the container with user namespace enabled. This flag conflicts with
447 --userns and --gidmap.
448
449
450 --subuidname=name
451 Name for UID map from the /etc/subuid file. Using this flag will run
452 the container with user namespace enabled. This flag conflicts with
453 --userns and --uidmap.
454
455
456 --sysctl=name=value
457 Configure namespace kernel parameters for all containers in the pod.
458
459
460 For the IPC namespace, the following sysctls are allowed:
461
462
463 • kernel.msgmax
464
465 • kernel.msgmnb
466
467 • kernel.msgmni
468
469 • kernel.sem
470
471 • kernel.shmall
472
473 • kernel.shmmax
474
475 • kernel.shmmni
476
477 • kernel.shm_rmid_forced
478
479 • Sysctls beginning with fs.mqueue.*
480
481
482
483 Note: if the ipc namespace is not shared within the pod, these sysctls
484 are not allowed.
485
486
487 For the network namespace, only sysctls beginning with net.* are al‐
488 lowed.
489
490
491 Note: if the network namespace is not shared within the pod, these
492 sysctls are not allowed.
493
494
495 --uidmap=container_uid:from_uid:amount
496 Run the container in a new user namespace using the supplied mapping.
497 This option conflicts with the --userns and --subuidname options. This
498 option provides a way to map host UIDs to container UIDs. It can be
499 passed several times to map different ranges.
500
501
502 --userns=mode
503 Set the user namespace mode for all the containers in a pod. It de‐
504 faults to the PODMAN_USERNS environment variable. An empty value ("")
505 means user namespaces are disabled.
506
507
508 Rootless user --userns=Key mappings:
509
510
511 ┌────────┬───────────┬─────────────────────┐
512 │Key │ Host User │ Container User │
513 ├────────┼───────────┼─────────────────────┤
514 │"" │ $UID │ 0 (Default User ac‐ │
515 │ │ │ count mapped to │
516 │ │ │ root user in con‐ │
517 │ │ │ tainer.) │
518 ├────────┼───────────┼─────────────────────┤
519 │keep-id │ $UID │ $UID (Map user ac‐ │
520 │ │ │ count to same UID │
521 │ │ │ within container.) │
522 ├────────┼───────────┼─────────────────────┤
523 │auto │ $UID │ nil (Host User UID │
524 │ │ │ is not mapped into │
525 │ │ │ container.) │
526 ├────────┼───────────┼─────────────────────┤
527 │nomap │ $UID │ nil (Host User UID │
528 │ │ │ is not mapped into │
529 │ │ │ container.) │
530 └────────┴───────────┴─────────────────────┘
531
532 Valid mode values are:
533
534
535 • auto[:OPTIONS,...]: automatically create a namespace. It is
536 possible to specify these options to auto:
537
538 • gidmapping=_CONTAINER_GID:HOSTGID:SIZE to force a GID mapping
539 to be present in the user namespace.
540
541 • size=SIZE: to specify an explicit size for the automatic user
542 namespace. e.g. --userns=auto:size=8192. If size is not speci‐
543 fied, auto will estimate a size for the user namespace.
544
545 • uidmapping=_CONTAINER_UID:HOSTUID:SIZE to force a UID mapping
546 to be present in the user namespace.
547
548 • host: run in the user namespace of the caller. The processes
549 running in the container will have the same privileges on the
550 host as any other process launched by the calling user (de‐
551 fault).
552
553 • keep-id: creates a user namespace where the current rootless
554 user's UID:GID are mapped to the same values in the container.
555 This option is ignored for containers created by the root
556 user.
557
558 • nomap: creates a user namespace where the current rootless
559 user's UID:GID are not mapped into the container. This option
560 is ignored for containers created by the root user.
561
562
563
564 --volume, -v[=[[SOURCE-VOLUME|HOST-DIR:]CONTAINER-DIR[:OPTIONS]]]
565 Create a bind mount. If you specify, -v /HOST-DIR:/CONTAINER-DIR, Pod‐
566 man bind mounts /HOST-DIR in the host to /CONTAINER-DIR in the Podman
567 container. Similarly, -v SOURCE-VOLUME:/CONTAINER-DIR will mount the
568 volume in the host to the container. If no such named volume exists,
569 Podman will create one. The OPTIONS are a comma-separated list and can
570 be: [1] ⟨#Footnote1⟩ (Note when using the remote client, including Mac
571 and Windows (excluding WSL2) machines, the volumes will be mounted from
572 the remote server, not necessarily the client machine.)
573
574
575 The options is a comma-separated list and can be:
576
577
578 • rw|ro
579
580 • z|Z
581
582 • [r]shared|[r]slave|[r]private[r]unbindable
583
584 • [r]bind
585
586 • [no]exec
587
588 • [no]dev
589
590 • [no]suid
591
592 • [O]
593
594 • [U]
595
596
597
598 The CONTAINER-DIR must be an absolute path such as /src/docs. The vol‐
599 ume will be mounted into the container at this directory.
600
601
602 Volumes may specify a source as well, as either a directory on the host
603 or the name of a named volume. If no source is given, the volume will
604 be created as an anonymously named volume with a randomly generated
605 name, and will be removed when the pod is removed via the --rm flag or
606 podman rm --volumes commands.
607
608
609 If a volume source is specified, it must be a path on the host or the
610 name of a named volume. Host paths are allowed to be absolute or rela‐
611 tive; relative paths are resolved relative to the directory Podman is
612 run in. If the source does not exist, Podman will return an error.
613 Users must pre-create the source files or directories.
614
615
616 Any source that does not begin with a . or / will be treated as the
617 name of a named volume. If a volume with that name does not exist, it
618 will be created. Volumes created with names are not anonymous, and
619 they are not removed by the --rm option and the podman rm --volumes
620 command.
621
622
623 You can specify multiple -v options to mount one or more volumes into
624 a pod.
625
626
627 Write Protected Volume Mounts
628
629
630 You can add :ro or :rw suffix to a volume to mount it read-only or
631 read-write mode, respectively. By default, the volumes are mounted
632 read-write. See examples.
633
634
635 Chowning Volume Mounts
636
637
638 By default, Podman does not change the owner and group of source volume
639 directories mounted into containers. If a pod is created in a new user
640 namespace, the UID and GID in the container may correspond to another
641 UID and GID on the host.
642
643
644 The :U suffix tells Podman to use the correct host UID and GID based on
645 the UID and GID within the pod, to change recursively the owner and
646 group of the source volume.
647
648
649 Warning use with caution since this will modify the host filesystem.
650
651
652 Labeling Volume Mounts
653
654
655 Labeling systems like SELinux require that proper labels are placed on
656 volume content mounted into a pod. Without a label, the security system
657 might prevent the processes running inside the pod from using the con‐
658 tent. By default, Podman does not change the labels set by the OS.
659
660
661 To change a label in the pod context, you can add either of two suf‐
662 fixes :z or :Z to the volume mount. These suffixes tell Podman to rela‐
663 bel file objects on the shared volumes. The z option tells Podman that
664 two pods share the volume content. As a result, Podman labels the con‐
665 tent with a shared content label. Shared volume labels allow all con‐
666 tainers to read/write content. The Z option tells Podman to label the
667 content with a private unshared label. Only the current pod can use a
668 private volume.
669
670
671 Overlay Volume Mounts
672
673
674 The :O flag tells Podman to mount the directory from the host as a tem‐
675 porary storage using the overlay file system. The pod processes can
676 modify content within the mountpoint which is stored in the container
677 storage in a separate directory. In overlay terms, the source directory
678 will be the lower, and the container storage directory will be the up‐
679 per. Modifications to the mount point are destroyed when the pod fin‐
680 ishes executing, similar to a tmpfs mount point being unmounted.
681
682
683 Subsequent executions of the container will see the original source di‐
684 rectory content, any changes from previous pod executions no longer ex‐
685 ist.
686
687
688 One use case of the overlay mount is sharing the package cache from the
689 host into the container to allow speeding up builds.
690
691
692 Note:
693
694
695 - The `O` flag conflicts with other options listed above.
696
697
698
699 Content mounted into the container is labeled with the private label.
700 On SELinux systems, labels in the source directory must be read‐
701 able by the infra container label. Usually containers can read/execute
702 container_share_t and can read/write container_file_t. If you cannot
703 change the labels on a source volume, SELinux container separation must
704 be disabled for the infra container/pod to work.
705 - The source directory mounted into the pod with an overlay mount
706 should not be modified, it can cause unexpected failures. It is recom‐
707 mended that you do not modify the directory until the container fin‐
708 ishes running.
709
710
711 Mounts propagation
712
713
714 By default bind mounted volumes are private. That means any mounts done
715 inside pod will not be visible on host and vice versa. One can change
716 this behavior by specifying a volume mount propagation property. Making
717 a volume shared mounts done under that volume inside pod will be visi‐
718 ble on host and vice versa. Making a volume slave enables only one way
719 mount propagation and that is mounts done on host under that volume
720 will be visible inside container but not the other way around. [1]
721 ⟨#Footnote1⟩
722
723
724 To control mount propagation property of a volume one can use the
725 [r]shared, [r]slave, [r]private or the [r]unbindable propagation flag.
726 For mount propagation to work the source mount point (the mount point
727 where source dir is mounted on) has to have the right propagation prop‐
728 erties. For shared volumes, the source mount point has to be shared.
729 And for slave volumes, the source mount point has to be either shared
730 or slave. [1] ⟨#Footnote1⟩
731
732
733 If you want to recursively mount a volume and all of its submounts into
734 a pod, then you can use the rbind option. By default the bind option is
735 used, and submounts of the source directory will not be mounted into
736 the pod.
737
738
739 Mounting the volume with the nosuid options means that SUID applica‐
740 tions on the volume will not be able to change their privilege. By de‐
741 fault volumes are mounted with nosuid.
742
743
744 Mounting the volume with the noexec option means that no executables on
745 the volume will be able to executed within the pod.
746
747
748 Mounting the volume with the nodev option means that no devices on the
749 volume will be able to be used by processes within the pod. By default
750 volumes are mounted with nodev.
751
752
753 If the <source-dir> is a mount point, then "dev", "suid", and "exec"
754 options are ignored by the kernel.
755
756
757 Use df <source-dir> to figure out the source mount and then use findmnt
758 -o TARGET,PROPAGATION <source-mount-dir> to figure out propagation
759 properties of source mount. If findmnt utility is not available, then
760 one can look at the mount entry for the source mount point in
761 /proc/self/mountinfo. Look at optional fields and see if any propaga‐
762 tion properties are specified. shared:X means mount is shared, mas‐
763 ter:X means mount is slave and if nothing is there that means mount is
764 private. [1] ⟨#Footnote1⟩
765
766
767 To change propagation properties of a mount point use mount command.
768 For example, if one wants to bind mount source directory /foo one can
769 do mount --bind /foo /foo and mount --make-private --make-shared /foo.
770 This will convert /foo into a shared mount point. Alternatively one can
771 directly change propagation properties of source mount. Say / is source
772 mount for /foo, then use mount --make-shared / to convert / into a
773 shared mount.
774
775
776 Note: if the user only has access rights via a group, accessing the
777 volume from inside a rootless pod will fail.
778
779
780 --volumes-from[=CONTAINER[:OPTIONS]]
781 Mount volumes from the specified container(s). Used to share volumes
782 between containers and pods. The options is a comma-separated list with
783 the following available elements:
784
785
786 • rw|ro
787
788 • z
789
790
791
792 Mounts already mounted volumes from a source container into another
793 pod. You must supply the source's container-id or container-name. To
794 share a volume, use the --volumes-from option when running the target
795 container. You can share volumes even if the source container is not
796 running.
797
798
799 By default, Podman mounts the volumes in the same mode (read-write or
800 read-only) as it is mounted in the source container. You can change
801 this by adding a ro or rw option.
802
803
804 Labeling systems like SELinux require that proper labels are placed on
805 volume content mounted into a pod. Without a label, the security system
806 might prevent the processes running inside the container from using the
807 content. By default, Podman does not change the labels set by the OS.
808
809
810 To change a label in the pod context, you can add z to the volume
811 mount. This suffix tells Podman to relabel file objects on the shared
812 volumes. The z option tells Podman that two entities share the volume
813 content. As a result, Podman labels the content with a shared content
814 label. Shared volume labels allow all containers to read/write content.
815
816
817 If the location of the volume from the source container overlaps with
818 data residing on a target pod, then the volume hides that data on the
819 target.
820
821
823 $ podman pod create --name test
824
825 $ podman pod create --infra=false
826
827 $ podman pod create --infra-command /top
828
829 $ podman pod create --publish 8443:443
830
831 $ podman pod create --network slirp4netns:outbound_addr=127.0.0.1,allow_host_loopback=true
832
833 $ podman pod create --network slirp4netns:cidr=192.168.0.0/24
834
835 $ podman pod create --network net1:ip=10.89.1.5 --network net2:ip=10.89.10.10
836
837
838
840 podman(1), podman-pod(1), containers.conf(1)
841
842
844 July 2018, Originally compiled by Peter Hunt pehunt@redhat.com
845 ⟨mailto:pehunt@redhat.com⟩
846
847
848
849 podman-pod-create(1)()