'\" t
.nh
.TH podman-run 1
.SH "نام (NAME)"
podman-run \- اجرای یک دستور در یک کانتینر جدید

.SH "خلاصه دستور (SYNOPSIS)"
\fBpodman run\fP [\fIگزینه‌ها\fP] \fIایمیج\fP [\fIدستور\fP [\fIآرگومان\fP ...]]

.PP
\fBpodman container run\fP [\fIگزینه‌ها\fP] \fIایمیج\fP [\fIدستور\fP [\fIآرگومان\fP ...]]

.SH "توضیحات (DESCRIPTION)"
اجرای یک فرایند در یک کانتینر جدید. دستور \fBpodman run\fP فرایندی را با سیستم‌فایل
اختصاصی، شبکه اختصاصی و درخت فرایند ایزوله‌شده خودش راه‌اندازی می‌کند. \fIایمیج\fPی
که فرایند را آغاز می‌کند ممکن است مقادیر پیش‌فرضی مرتبط با فرایندی که قرار است
در کانتینر اجرا شود، شبکه‌ای که باید در دسترس قرار گیرد و موارد دیگر تعریف کند، اما \fBpodman run\fP
کنترل نهایی را در اختیار مجری یا مدیری قرار می‌دهد که کانتینر را از آن ایمیج اجرا می‌کند.
به همین دلیل، \fBpodman run\fP بیش از هر دستور دیگری در پادمن دارای گزینه است.

.PP
اگر \fIایمیج\fP از قبل بارگیری نشده باشد، \fBpodman run\fP پیش از شروع کانتینر،
\fIایمیج\fP و تمام وابستگی‌های آن را مانند اجرای دستور \fBpodman pull\fP \fIایمیج\fP
از مخزن دریافت (pull) می‌کند.

.PP
چندین فایل به صورت خودکار درون کانتینر ایجاد می‌شوند. این فایل‌ها شامل
\fI/etc/hosts\fP، \fI/etc/hostname\fP و \fI/etc/resolv.conf\fP برای مدیریت شبکه هستند.
این فایل‌ها بر اساس نسخه میزبان ساخته می‌شوند، اگرچه می‌توان آن‌ها را با استفاده از گزینه‌ها
سفارشی‌سازی کرد (برای مثال، گزینه \fB--dns\fP می‌تواند کارسازهای DNS میزبان را در \fIresolv.conf\fP
ایجادشده بازنویسی کند). علاوه بر این، یک فایل محیط کانتینر در هر کانتینر ایجاد می‌شود تا به
برنامه‌ها نشان دهد درون یک کانتینر در حال اجرا هستند. این فایل در مسیر \fI/run/.containerenv\fP
(یا برای کانتینرهای FreeBSD در مسیر \fI/var/run/.containerenv\fP) قرار دارد. هنگام استفاده از پرچم
--privileged، فایل .containerenv شامل جفت‌های نام/مقدار است که نسخه موتور کانتینر، اجرای موتور
در حالت بدون ریشه (rootless)، نام و شناسه کانتینر و همچنین نام و شناسه ایمیجی که کانتینر بر پایه آن
ساخته شده را نشان می‌دهد. نکته: در صورت مانت شدن یک حجم روی /run، فایل \fI/run/.containerenv\fP ایجاد نخواهد شد.

.PP
هنگام اجرا در یک فضای نام شبکه تعریف‌شده توسط کاربر، فایل \fI/etc/netns/NSNAME/resolv.conf\fP در صورت
وجود استفاده خواهد شد؛ در غیر این صورت از \fI/etc/resolv.conf\fP استفاده می‌شود.

.PP
تنظیمات پیش‌فرض در \fBcontainers.conf\fR تعریف شده‌اند. بیشتر تنظیمات برای اتصالات راه دور
از containers.conf سرورها استفاده می‌کنند، مگر مواردی که در صفحات راهنما مستند شده باشد.

.SH "ایمیج (IMAGE)"
ایمیج با استفاده از قالب transport:path مشخص می‌شود. اگر نوع انتقال (transport) مشخص نشود،
انتقال \fBdocker\fR (رجیستری کانتینر) به صورت پیش‌فرض استفاده می‌شود. برای پادمن راه دور (ریموت)،
شامل ماشین‌های مک و ویندوز (به استثنای WSL2)، انتقال \fBdocker\fR تنها انتقال مجاز است.

.PP
\fBdir:\fP\fIpath\fP
  یک مسیر دایرکتوری محلی موجود \fIpath\fP که مانیفست، لایه‌های tarball و امضاها را
به‌عنوان فایل‌های جداگانه ذخیره می‌کند. این یک فرمت غیراستاندارد است که در درجه اول برای رفع اشکال یا
بازرسی غیرتهاجمی کانتینر کاربرد دارد.

.EX
$ podman save --format docker-dir fedora -o /tmp/fedora
$ podman run dir:/tmp/fedora echo hello
.EE

.PP
\fBdocker://\fP\fIdocker-reference\fP (پیش‌فرض)
  یک ارجاع ایمیج ذخیره‌شده در یک رجیستری ایمیج کانتینر راه دور. مثال: "quay.io/podman/stable:latest".
مرجع می‌تواند شامل مسیری به یک رجیستری خاص باشد؛ اگر شامل آن نباشد، رجیستری‌های فهرست‌شده در
registries.conf برای یافتن یک ایمیج منطبق پرس‌وجو می‌شوند.
به صورت پیش‌فرض، اطلاعات احراز هویت حاصل از \fBpodman login\fR (که به طور پیش‌فرض در
$XDG_RUNTIME_DIR/containers/auth.json ذخیره می‌شود) برای اعتبارسنجی استفاده می‌شود؛
در غیر این صورت، به استفاده از اعتبارهای موجود در $HOME/.docker/config.json بازمی‌گردد.

.EX
$ podman run registry.fedoraproject.org/fedora:latest echo hello
.EE

.PP
\fBdocker-archive:\fP\fIpath\fP[\fB:\fP\fIdocker-reference\fP]
یک ایمیج ذخیره‌شده در فایل با قالب \fBdocker save\fR. عبارت \fIdocker-reference\fP تنها هنگام ایجاد
چنین فایلی استفاده می‌شود و نباید حاوی شناسه یکتای دایجست (digest) باشد.

.EX
$ podman save --format docker-archive fedora -o /tmp/fedora
$ podman run docker-archive:/tmp/fedora echo hello
.EE

.PP
نکته: در کلاینت‌های ریموت، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2)، این نوع انتقال پشتیبانی نمی‌شود.

.PP
\fBdocker-daemon:\fP\fIdocker-reference\fP
  یک ایمیج در قالب \fIdocker-reference\fP که در حافظه ذخیره‌سازی داخلی دیمن داکر ذخیره شده است.
\fIdocker-reference\fP می‌تواند یک شناسه ایمیج نیز باشد (docker-daemon:algo:digest).

.EX
$ sudo docker pull fedora
$ sudo podman run docker-daemon:docker.io/library/fedora echo hello
.EE

.PP
نکته: در کلاینت‌های ریموت، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2)، این نوع انتقال پشتیبانی نمی‌شود.

.PP
\fBoci-archive:\fP\fIpath\fP\fB:\fP\fItag\fP
  یک ایمیج در یک دایرکتوری منطبق با "Open Container Image Layout Specification" در \fIpath\fP مشخص‌شده
و با یک برچسب \fItag\fP\&.

.EX
$ podman save --format oci-archive fedora -o /tmp/fedora
$ podman run oci-archive:/tmp/fedora echo hello
.EE

.PP
نکته: در کلاینت‌های ریموت، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2)، این نوع انتقال پشتیبانی نمی‌شود.

.SH "گزینه‌ها (OPTIONS)"
.SS \fB--add-host\fP=\fIhostname[;hostname[;...]]\fP:\fIip\fP
افزودن نگاشت سفارشی میزبان به IP در فایل \fB/etc/hosts\fR کانتینر.

.PP
این گزینه یک یا چند نام میزبان جداشده با نقطه‌ویرگول را می‌گیرد تا به یک نشانی IPv4 یا IPv6 با جداکننده دو نقطه نگاشت شوند. همچنین می‌توان از آن برای بازنویسی نشانی‌های IP نام‌های میزبانی که پادمن به صورت پیش‌فرض به \fB/etc/hosts\fR اضافه می‌کند استفاده کرد (گزینه‌های \fB--name\fP و \fB--hostname\fP را نیز ببینید). این گزینه را می‌توان چندین بار برای افزودن نگاشت‌های بیشتر به \fB/etc/hosts\fR مشخص کرد. این گزینه با گزینه \fB--no-hosts\fP و \fIno_hosts=true\fP در \fBcontainers.conf\fR تداخل دارد.

.PP
به‌جای نشانی IP، می‌توان پرچم ویژه \fIhost-gateway\fP را داد. این به نشانی IP که کانتینر می‌تواند برای اتصال به میزبان استفاده کند ترجمه می‌شود. نشانی IP انتخاب‌شده به پیکربندی شبکه شما بستگی دارد، بنابراین تضمینی وجود ندارد که پادمن بتواند نشانی \fIhost-gateway\fP را به صورت خودکار تشخیص دهد، که در این صورت پادمن با یک پیام خطا متوقف می‌شود. می‌توانید این نشانی IP را با استفاده از گزینه \fIhost_containers_internal_ip\fP در \fIcontainers.conf\fP بازنویسی کنید.

.PP
نشانی \fIhost-gateway\fP همچنین توسط پادمن برای افزودن خودکار نام‌های میزبان \fBhost.containers.internal\fR و \fBhost.docker.internal\fR به \fB/etc/hosts\fR استفاده می‌شود. می‌توانید با دادن گزینه \fB--no-hosts\fP یا با تنظیم \fIhost_containers_internal_ip="none"\fP در \fIcontainers.conf\fP از آن جلوگیری کنید. اگر هیچ نشانی \fIhost-gateway\fP به صورت دستی پیکربندی نشده باشد و پادمن نتواند نشانی IP را به صورت خودکار تعیین کند، پادمن بدون نمایش پیام از افزودن این نام‌های میزبان داخلی به \fB/etc/hosts\fR صرف‌نظر می‌کند. اگر پادمن در یک ماشین مجازی با استفاده از \fBpodman machine\fR در حال اجرا باشد (شامل میزبان‌های مک و ویندوز)، پادمن از افزودن نام‌های میزبان داخلی به \fB/etc/hosts\fR صرف‌نظر می‌کند، مگر اینکه نشانی IP به صورت دستی تنظیم شده باشد؛ در عوض نام‌های میزبان داخلی توسط تحلیل‌گر DNS با نام gvproxy تحلیل می‌شوند.

.PP
پادمن به صورت پیش‌فرض از فایل \fB/etc/hosts\fR میزبان به عنوان پایه استفاده می‌کند، یعنی هر نام میزبانی که در این فایل وجود دارد در فایل \fB/etc/hosts\fR کانتینر نیز حضور خواهد داشت. می‌توان یک فایل پایه متفاوت را با استفاده از پیکربندی \fIbase_hosts_file\fP در \fBcontainers.conf\fR تنظیم کرد.

.SS \fB--annotation\fP=\fIkey=value\fP
افزودن یادداشت (annotation) به کانتینر. این گزینه می‌تواند چندین بار تنظیم شود.

.SS \fB--arch\fP=\fIARCH\fP
بازنویسی معماری ایمیجی که باید دریافت شود (پیش‌فرض معماری میزبان است). برای مثال، \fBarm\fR\&.
مگر اینکه بازنویسی شود، جستجوهای بعدی همان ایمیج در حافظه محلی با این معماری مطابقت خواهند داشت، صرف‌نظر از میزبان.

.SS \fB--attach\fP, \fB-a\fP=\fIstdin\fP | \fIstdout\fP | \fIstderr\fP
اتصال به STDIN، STDOUT یا STDERR.

.PP
در حالت پیش‌زمینه (پیش‌فرض زمانی که \fB-d\fP مشخص نشده باشد)، \fBpodman run\fP می‌تواند فرایند را در کانتینر آغاز کرده و کنسول را به ورودی استاندارد، خروجی و خطای استاندارد فرایند متصل کند. حتی می‌تواند مانند یک TTY رفتار کند (چیزی که اکثر فایل‌های اجرایی خط فرمان انتظار دارند) و سیگنال‌ها را منتقل نماید. گزینه \fB-a\fP می‌تواند برای هر یک از \fBstdin\fP، \fBstdout\fP و \fBstderr\fP تنظیم شود.

.SS \fB--authfile\fP=\fIpath\fP
مسیر فایل احراز هویت. پیش‌فرض در لینوکس \fB${XDG_RUNTIME_DIR}/containers/auth.json\fR و در ویندوز/مک‌او‌اس \fB$HOME/.config/containers/auth.json\fR است.
این فایل توسط \fBpodman login\fP ایجاد می‌شود. اگر وضعیت مجوز در آنجا یافت نشود، \fB$HOME/.docker/config.json\fR بررسی می‌شود که با \fBdocker login\fP تنظیم شده است.

.PP
نکته: همچنین گزینه بازنویسی مسیر پیش‌فرض فایل احراز هویت با تنظیم متغیر محیطی \fBREGISTRY_AUTH_FILE\fR وجود دارد. این کار را می‌توان با \fBexport REGISTRY_AUTH_FILE=\fIpath\fP\fP انجام داد.

.SS \fB--blkio-weight\fP=\fIweight\fP
وزن نسبی Block IO. مقدار \fIweight\fP عددی بین \fB10\fP و \fB1000\fP است.

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--blkio-weight-device\fP=\fIdevice:weight\fP
وزن نسبی دستگاه Block IO.

.SS \fB--cap-add\fP=\fIcapability\fP
افزودن قابلیت‌های لینوکس (Linux capabilities).

.PP
اعطای قابلیت‌های بیشتر امتیازات فرایندهای در حال اجرا در کانتینر را افزایش داده و به طور بالقوه امکان خروج از محدوده ایزولاسیون را فراهم می‌کند. قابلیت‌هایی مانند \fBCAP_SYS_ADMIN\fR، \fBCAP_SYS_PTRACE\fR، \fBCAP_MKNOD\fR و \fBCAP_SYS_MODULE\fR به ویژه زمانی که در یک فضای نام کاربری استفاده نشوند خطرناک هستند. لطفاً برای توضیح دقیق‌تر درباره تعامل میان فضاهای نام کاربری و قابلیت‌ها به \fBuser_namespaces(7)\fP مراجعه کنید.

.PP
پیش از افزودن هر قابلیتی، پیامدهای امنیتی آن را بررسی کرده و اطمینان حاصل کنید که برای عملکرد کانتینر واقعاً ضروری است. برای اطلاعات بیشتر \fBcapabilities(7)\fP را ببینید.

.SS \fB--cap-drop\fP=\fIcapability\fP
حذف این قابلیت‌ها از مجموعه قابلیت‌های پیش‌فرض پادمن، یا \fBall\fR برای حذف تمامی قابلیت‌ها.

.PP
این یک لیست از قابلیت‌ها است که با فاصله از هم جدا شده‌اند.

.SS \fB--cert-dir\fP=\fIpath\fP
استفاده از گواهی‌ها در \fIpath\fP (*\&.crt, *\&.cert, *\&.key) برای اتصال به رجیستری (پیش‌فرض: etc/containers/certs.d/).
برای جزئیات به \fBcontainers-certs.d(5)\fP مراجعه کنید.
(این گزینه در کلاینت ریموت پادمن، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) در دسترس نیست)

.SS \fB--cgroup-conf\fP=\fIKEY=VALUE\fP
هنگام اجرا روی cgroup v2، فایل cgroup و مقدار مورد نظر برای نوشتن در آن را مشخص می‌کند. برای مثال \fB--cgroup-conf=memory.high=1073741824\fP محدودیت memory.high را روی 1GB تنظیم می‌کند.

.SS \fB--cgroup-parent\fP=\fIpath\fP
مسیر cgroups که cgroup کانتینر تحت آن ایجاد می‌شود. اگر مسیر مطلق نباشد، مسیر نسبت به مسیر cgroups فرایند init در نظر گرفته می‌شود. Cgroups در صورتی که از قبل وجود نداشته باشند ایجاد می‌شوند.

.SS \fB--cgroupns\fP=\fImode\fP
تنظیم حالت فضای نام cgroup برای کانتینر.
.IP \(bu 2
\fBhost\fP: استفاده از فضای نام cgroup میزبان درون کانتینر.
.IP \(bu 2
\fBcontainer:\fP\fIid\fP: پیوستن به فضای نام کانتینر مشخص‌شده.
.IP \(bu 2
\fBprivate\fP: ایجاد یک فضای نام cgroup جدید.
.IP \(bu 2
\fBns:\fP\fIpath\fP: پیوستن به فضای نام در مسیر مشخص‌شده.

.PP
اگر میزبان از cgroups v1 استفاده کند، پیش‌فرض روی \fBhost\fP تنظیم می‌شود. در cgroups v2، پیش‌فرض \fBprivate\fP است.

.SS \fB--cgroups\fP=\fIhow\fP
تعیین می‌کند که آیا کانتینر cgroups ایجاد کند یا خیر.

.PP
پیش‌فرض \fBenabled\fP است.

.PP
گزینه \fBenabled\fP یک cgroup جدید تحت cgroup-parent ایجاد می‌کند.
گزینه \fBdisabled\fP کانتینر را مجبور می‌کند که cgroups نسازد، بنابراین با گزینه‌های cgroup (\fB--cgroupns\fP و \fB--cgroup-parent\fP) تداخل دارد.
گزینه \fBno-conmon\fP ساخت cgroup جدید را فقط برای فرایند \fBconmon\fP غیرفعال می‌کند.
گزینه \fBsplit\fP گروه cgroup فعلی را به دو زیرگروه تقسیم می‌کند: یکی برای conmon و دیگری برای بار مفید کانتینر. با \fBsplit\fP نمی‌توان \fB--cgroup-parent\fP را تنظیم کرد.

.SS \fB--chrootdirs\fP=\fIpath\fP
مسیر به دایرکتوری درون کانتینر که به عنوان یک دایرکتوری \fBchroot\fR تلقی می‌شود.
هر فایل تحت مدیریت پادمن (مانند etc/resolv.conf/، /etc/hosts، /etc/hostname) که درون دایرکتوری root مانت شده باشد، در آن مکان نیز مانت می‌شود.
چندین دایرکتوری با کاما از هم جدا می‌شوند.

.SS \fB--cidfile\fP=\fIfile\fP
نوشتن شناسه کانتینر در \fIfile\fP\&. فایل همراه با کانتینر حذف می‌شود، مگر زمانی که با podman --remote run روی کانتینرهای جداشده (detached) استفاده شود.

.SS \fB--conmon-pidfile\fP=\fIfile\fP
نوشتن pid فرایند \fBconmon\fP در یک فایل. از آنجا که \fBconmon\fP در فرایندی جدا از پادمن اجرا می‌شود، هنگام استفاده از systemd برای راه‌اندازی مجدد کانتینرهای پادمن این گزینه ضروری است.
(این گزینه در کلاینت ریموت پادمن، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) در دسترس نیست)

.SS \fB--cpu-period\fP=\fIlimit\fP
تنظیم دوره CPU برای زمان‌بند کاملاً منصفانه (CFS) که مدت زمانی بر حسب میکروثانیه است. پس از اتمام سهمیه CPU کانتینر، تا پایان دوره فعلی برای اجرا زمان‌بندی نخواهد شد. پیش‌فرض 100000 میکروثانیه است.

.PP
در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید:
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--cpu-quota\fP=\fIlimit\fP
محدود کردن سهمیه زمان‌بند کاملاً منصفانه (CFS) پردازنده.

.PP
محدود کردن میزان استفاده پردازنده توسط کانتینر. به طور پیش‌فرض، کانتینرها با تمام منابع CPU اجرا می‌شوند. محدودیت عددی بر حسب میکروثانیه است. در صورت ارائه یک عدد، کانتینر مجاز است تا پایان دوره CPU (قابل کنترل از طریق \fB--cpu-period\fP) از همان مقدار زمان پردازنده استفاده کند.

.PP
در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید:
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--cpu-rt-period\fP=\fImicroseconds\fP
محدود کردن دوره بی‌درنگ (Real-Time) پردازنده بر حسب میکروثانیه.

.PP
محدود کردن استفاده بلادرنگ کانتینر از پردازنده. این گزینه به کرنل دستور می‌دهد که استفاده بلادرنگ کانتینر از پردازنده را به دوره مشخص‌شده محدود کند.

.PP
این گزینه تنها در سیستم‌های دارای ریشه (rootful) با cgroups V1 پشتیبانی می‌شود.

.SS \fB--cpu-rt-runtime\fP=\fImicroseconds\fP
محدود کردن زمان اجرای بی‌درنگ (Real-Time) پردازنده بر حسب میکروثانیه.

.PP
محدود کردن استفاده بی‌درنگ کانتینر از پردازنده. این گزینه به کرنل دستور می‌دهد مدت زمانی را که تسک‌های بی‌درنگ در یک دوره CPU مشخص می‌توانند مصرف کنند محدود کند. برای مثال:
دوره 1,000,000us و زمان اجرای 950,000us به این معنی است که این کانتینر می‌تواند 95% از پردازنده موجود را مصرف کند و 5% باقی‌مانده را برای تسک‌های با اولویت عادی بگذارد.

.PP
مجموع کل زمان‌های اجرا در میان کانتینرها نمی‌تواند از مقدار اختصاص‌یافته به cgroup والد فراتر رود.

.PP
این گزینه تنها در سیستم‌های دارای ریشه با cgroups V1 پشتیبانی می‌شود.

.SS \fB--cpu-shares\fP, \fB-c\fP=\fIshares\fP
سهم‌های پردازنده (وزن نسبی).

.PP
به طور پیش‌فرض، همه کانتینرها سهم یکسانی از چرخه‌های CPU دریافت می‌کنند. این نسبت را می‌توان با تغییر وزن سهم پردازنده کانتینر نسبت به وزن ترکیبی همه کانتینرهای در حال اجرا تغییر داد.
وزن پیش‌فرض \fB1024\fP است.

.PP
این نسبت تنها زمانی اعمال می‌شود که فرایندهای سنگین پردازشی در حال اجرا باشند.
وقتی تسک‌ها در یک کانتینر بی‌کار باشند، سایر کانتینرها می‌توانند از زمان باقی‌مانده CPU استفاده کنند. مقدار واقعی زمان CPU بسته به تعداد کانتینرهای در حال اجرا در سیستم متغیر است.

.PP
برای مثال، سه کانتینر را در نظر بگیرید، یکی دارای cpu-share برابر 1024 و دو کانتینر دیگر دارای تنظیم cpu-share برابر 512 هستند. هنگامی که فرایندها در هر سه کانتینر تلاش می‌کنند از 100% پردازنده استفاده کنند، کانتینر اول 50% از کل زمان CPU را دریافت می‌کند. اگر کانتینر چهارمی با cpu-share برابر 1024 اضافه شود، کانتینر اول تنها 33% از CPU را دریافت می‌کند. کانتینرهای باقی‌مانده به ترتیب 16.5%، 16.5% و 33% از CPU را دریافت می‌نمایند.

.PP
در یک سیستم چند هسته‌ای، سهم‌های زمان CPU بین تمام هسته‌های پردازنده توزیع می‌شود. حتی اگر یک کانتینر به کمتر از 100% زمان پردازنده محدود شده باشد، می‌تواند از 100% هر یک از هسته‌های پردازنده به صورت جداگانه استفاده کند.

.PP
برای مثال، سیستمی با بیش از سه هسته را در نظر بگیرید.
اگر کانتینر \fIC0\fP با \fB--cpu-shares=512\fP با یک فرایند اجرا شود، و کانتینر دیگری با نام \fIC1\fP با \fB--cpu-shares=1024\fP با دو فرایند اجرا شود، این امر می‌تواند به تقسیم سهم‌های CPU به شرح زیر منجر شود:

.TS
allbox;
l l l l 
l l l l .
\fBPID\fP	\fBcontainer\fP	\fBCPU\fP	\fBCPU share\fP
100	C0	0	100% of CPU0
101	C1	1	100% of CPU1
102	C1	2	100% of CPU2
.TE

.PP
در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید:
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--cpus\fP=\fInumber\fP
تعداد پردازنده‌ها. پیش‌فرض \fI0.0\fP به معنای عدم وجود محدودیت است. این گزینه حالت خلاصه‌شده \fB--cpu-period\fP و \fB--cpu-quota\fP است، بنابراین نمی‌توان آن را همراه با \fB--cpu-period\fP یا \fB--cpu-quota\fP مشخص کرد.

.PP
در برخی سیستم‌ها، تغییر محدودیت‌های CPU ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید:
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--cpuset-cpus\fP=\fInumber\fP
پردازنده‌هایی که اجرا در آن‌ها مجاز است. می‌توان به صورت یک لیست جداشده با کاما (مانند \fB0,1\fP)، به عنوان یک بازه (مانند \fB0-3\fP) یا هر ترکیبی از آن‌ها (مانند \fB0-3,7,11-15\fP) مشخص کرد.

.PP
در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید:
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--cpuset-mems\fP=\fInodes\fP
گره‌های حافظه (MEMs) که اجرا در آن‌ها مجاز است (0-3، 0,1). تنها در سیستم‌های NUMA موثر است.

.PP
اگر چهار گره حافظه در سیستم وجود داشته باشد (0-3)، با استفاده از \fB--cpuset-mems=0,1\fP فرایندهای درون کانتینر تنها از حافظه دو گره حافظه اول استفاده می‌کنند.

.PP
در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید:
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--creds\fP=\fI[username[:password]]\fP
ترکیب [نام‌کاربری[:رمز‌عبور]] برای احراز هویت در رجیستری، در صورت لزوم.
اگر یک یا هر دو مقدار ارائه نشوند، اعلان خط فرمان ظاهر شده و می‌توان مقدار را وارد کرد. رمز عبور بدون بازتاب (echo) وارد می‌شود.

.PP
توجه داشته باشید که اعتبارهای مشخص‌شده تنها برای احراز هویت در رجیستری‌های هدف استفاده می‌شوند. آن‌ها برای آینه‌ها (mirrors) یا زمانی که رجیستری بازنویسی می‌شود استفاده نمی‌شوند (به \fBcontainers-registries.conf(5)\fR مراجعه کنید)؛ برای احراز هویت در برابر آن‌ها استفاده از فایل \fBcontainers-auth.json(5)\fR را در نظر بگیرید.

.SS \fB--decryption-key\fP=\fIkey[:passphrase]\fP
ترکیب [key[:passphrase]] مورد استفاده برای رمزگشایی ایمیج‌ها. کلید می‌تواند به کلیدها و/یا گواهی‌ها اشاره کند. رمزگشایی با تمام کلیدها امتحان می‌شود. اگر کلید با یک عبارت عبور محافظت شده باشد، ارسال آن در آرگومان الزامی است و در غیر این صورت حذف می‌شود.

.SS \fB--detach\fP, \fB-d\fP
حالت جداشده (Detached): اجرای کانتینر در پس‌زمینه و چاپ شناسه کانتینر جدید. مقدار پیش‌فرض \fIfalse\fP است.

.PP
در هر زمان می‌توانید \fBpodman ps\fP را در شل دیگری اجرا کنید تا فهرستی از کانتینرهای در حال اجرا را ببینید. با دستور \fBpodman attach\fP مجدداً به یک کانتینر جداشده متصل شوید.

.PP
هنگام اتصال از طریق حالت tty، با استفاده از توالی کلیدهای قابل تنظیم از کانتینر جدا شوید (و بگذارید در حال اجرا بماند). توالی پیش‌فرض \fBctrl-p,ctrl-q\fR است. توالی کلیدها را با استفاده از گزینه \fB--detach-keys\fP مشخص کنید، یا آن را در فایل \fBcontainers.conf\fP پیکربندی نمایید؛ برای اطلاعات بیشتر به \fBcontainers.conf(5)\fP مراجعه کنید.

.SS \fB--detach-keys\fP=\fIsequence\fP
توالی کلیدها را برای جدا شدن از کانتینر مشخص می‌کند. قالب آن یک نویسه تکی \fB[a-Z]\fR یا یک یا چند نویسه \fBctrl-<value>\fR است که در آن \fB<value>\fR یکی از این موارد است: \fBa-z\fR، \fB@\fR، \fB^\fR، \fB[\fR، \fB,\fR یا \fB_\fR\&. مشخص کردن "" این ویژگی را غیرفعال می‌کند. مقدار پیش‌فرض \fIctrl-p,ctrl-q\fP است.

.PP
این گزینه همچنین می‌تواند در فایل \fBcontainers.conf\fP(5) تنظیم شود.

.SS \fB--device\fP=\fIhost-device[:container-device][:permissions]\fP
افزودن دستگاه میزبان به کانتینر. فرمت آن به صورت \fBHOST-DEVICE[:CONTAINER-DEVICE][:PERMISSIONS]\fR است که در آن \fBHOST-DEVICE\fR مسیر گره دستگاه روی میزبان، \fBCONTAINER-DEVICE\fR مسیر گره دستگاه در کانتینر، و \fBPERMISSIONS\fR فهرستی از مجوزها شامل 'r' برای خواندن، 'w' برای نوشتن، و 'm' برای mknod(2) است.

.PP
مثال: \fB--device=/dev/sdc:/dev/xvdc:rwm\fP\&.

.PP
نکته: اگر \fIhost-device\fP یک پیوند نمادین باشد ابتدا تحلیل می‌شود. کانتینر تنها شماره‌های اصلی و فرعی دستگاه میزبان را ذخیره می‌کند.

.PP
پادمن ممکن است ماژول‌های کرنل مورد نیاز برای استفاده از دستگاه مشخص‌شده را بارگیری کند. دستگاه‌هایی که پادمن در صورت لزوم ماژول‌های آن‌ها را بارگیری می‌کند عبارتند از: dev/fuse/.

.PP
در حالت بدون ریشه (rootless)، دستگاه جدید به‌جای ایجاد شدن توسط پادمن درون فضای کانتینر، از میزبان به صورت bind mount درون کانتینر مانت می‌شود. از آنجا که bind mount برچسب SELinux خود را در سیستم‌های SELinux حفظ می‌کند، ممکن است کانتینر هنگام دسترسی به دستگاه مانت‌شده با خطای عدم دسترسی مواجه شود. تنظیمات SELinux را تغییر دهید تا به کانتینرها اجازه داده شود از تمام برچسب‌های دستگاه از طریق دستور زیر استفاده کنند:

.PP
$ sudo setsebool -P container_use_devices=true

.PP
نکته: اگر کاربر تنها از طریق یک گروه دارای حقوق دسترسی باشد، دسترسی به دستگاه از داخل کانتینر بدون ریشه با شکست مواجه می‌شود. از پرچم \fB--group-add keep-groups\fR برای انتقال دسترسی گروه تکمیلی کاربر به داخل کانتینر استفاده کنید.

.SS \fB--device-cgroup-rule\fP=\fI"type major:minor mode"\fP
افزودن قاعده به لیست دستگاه‌های مجاز cgroup. انتظار می‌رود این قاعده در قالبی باشد که در مستندات کرنل لینوکس admin-guide/cgroup-v1/devices مشخص شده است:
- \fItype\fP: به صورت \fBa\fR (همه)، \fBc\fR (کاراکتری)، یا \fBb\fR (بلوکی)؛
- \fImajor\fP و \fIminor\fP: یا یک عدد، یا \fB*\fR برای همه؛
- \fImode\fP: ترکیبی از \fBr\fR (خواندن)، \fBw\fR (نوشتن)، و \fBm\fR (mknod(2)).

.SS \fB--device-read-bps\fP=\fIpath:rate\fP
محدود کردن نرخ خواندن (بر حسب بایت بر ثانیه) از یک دستگاه (مانند \fB--device-read-bps=/dev/sda:1mb\fP).

.PP
در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید:
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--device-read-iops\fP=\fIpath:rate\fP
محدود کردن نرخ خواندن (بر حسب عملیات IO در ثانیه) از یک دستگاه (مانند \fB--device-read-iops=/dev/sda:1000\fP).

.PP
در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید:
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--device-write-bps\fP=\fIpath:rate\fP
محدود کردن نرخ نوشتن (بر حسب بایت بر ثانیه) روی یک دستگاه (مانند \fB--device-write-bps=/dev/sda:1mb\fP).

.PP
در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید:
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--device-write-iops\fP=\fIpath:rate\fP
محدود کردن نرخ نوشتن (بر حسب عملیات IO در ثانیه) روی یک دستگاه (مانند \fB--device-write-iops=/dev/sda:1000\fP).

.PP
در برخی سیستم‌ها، تغییر محدودیت‌های منابع ممکن است برای کاربران غیر ریشه مجاز نباشد. برای جزئیات بیشتر به لینک زیر مراجعه کنید:
https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--disable-content-trust\fP
این یک گزینه مخصوص داکر برای غیرفعال کردن اعتبارسنجی ایمیج در رجیستری کانتینر است و توسط پادمن پشتیبانی نمی‌شود. این گزینه یک دستور بی‌اثر (NOOP) است و صرفاً برای سازگاری اسکریپت‌ها ارائه شده است.

.SS \fB--dns\fP=\fIipaddr\fP
تنظیم کارسازهای DNS سفارشی.

.PP
این گزینه می‌تواند برای بازنویسی پیکربندی DNS ارائه‌شده به کانتینر استفاده شود. معمولاً زمانی که پیکربندی DNS میزبان برای کانتینر نامعتبر است (مانند \fB127.0.0.1\fP) ضروری است. هنگامی که چنین است، پرچم \fB--dns\fP برای هر بار اجرا لازم است.

.PP
مقدار ویژه \fBnone\fP را می‌توان برای غیرفعال‌سازی ساخت فایل \fI/etc/resolv.conf\fP در کانتینر توسط پادمن مشخص کرد. در این صورت فایل \fI/etc/resolv.conf\fP موجود در ایمیج بدون تغییر استفاده می‌شود.

.PP
توجه داشته باشید که \fBipaddr\fP ممکن است مستقیماً به \fI/etc/resolv.conf\fP کانتینر اضافه شود؛ اما این موضوع قطعی نیست. برای مثال، ارسال یک شبکه سفارشی که \fIdns_enabled\fP آن روی \fItrue\fP تنظیم شده به \fB--network\fP باعث می‌شود که \fI/etc/resolv.conf\fP تنها به سرور aardvark-dns ارجاع دهد. سپس aardvark-dns برای تمام پرس‌وجوهای نام‌های غیر کانتینری درخواست را به \fBipaddr\fP ارائه‌شده فوروارد می‌کند.

.PP
این گزینه نمی‌تواند با \fB--network\fP که روی \fBnone\fP یا \fBcontainer:\fP\fIid\fP تنظیم شده ترکیب شود.

.SS \fB--dns-option\fP=\fIoption\fP
تنظیم گزینه‌های سفارشی DNS. در صورت استفاده از \fB--dns-option\fP همراه با \fB--network\fP تنظیم‌شده روی \fBnone\fP یا \fBcontainer:\fP\fIid\fP نامعتبر است.

.SS \fB--dns-search\fP=\fIdomain\fP
تنظیم دامنه‌های جستجوی سفارشی DNS. در صورت استفاده از \fB--dns-search\fP همراه با \fB--network\fP تنظیم‌شده روی \fBnone\fP یا \fBcontainer:\fP\fIid\fP نامعتبر است.
برای حذف دامنه جستجو از \fB--dns-search=.\fP استفاده کنید.

.SS \fB--entrypoint\fP=\fI"command"\fP | \fI\&'["command", "arg1", ...]'\fP
بازنویسی ENTRYPOINT پیش‌فرض از ایمیج.

.PP
نقطه ورود (ENTRYPOINT) یک ایمیج مشابه یک COMMAND است زیرا مشخص می‌کند چه فایل اجرایی هنگام شروع کانتینر اجرا شود، اما (عامدانه) بازنویسی آن دشوارتر است. ENTRYPOINT ماهیت یا رفتار پیش‌فرض را به یک کانتینر می‌دهد. هنگامی که ENTRYPOINT تنظیم می‌شود، کانتینر طوری اجرا می‌شود که گویی همان باینری است، به همراه گزینه‌های پیش‌فرض کامل. گزینه‌های بیشتر را می‌توان از طریق COMMAND ارسال کرد. اما اگر کاربری بخواهد چیز دیگری درون کانتینر اجرا کند، گزینه \fB--entrypoint=\fP اجازه می‌دهد یک ENTRYPOINT جدید مشخص شود.

.PP
دستورات چندگزینه‌ای را در قالب یک رشته JSON مشخص کنید.

.SS \fB--env\fP, \fB-e\fP=\fIenv\fP
تنظیم متغیرهای محیطی.

.PP
این گزینه متغیرهای محیطی دلخواهی را که برای فرایند مورد نظر جهت راه‌اندازی در داخل کانتینر در دسترس هستند، تنظیم می‌کند. اگر متغیر محیطی بدون مقدار مشخص شود، پادمن محیط میزبان را برای یافتن مقدار بررسی می‌کند و متغیر را تنها در صورتی تنظیم می‌کند که روی میزبان تنظیم شده باشد. به عنوان یک حالت خاص، اگر متغیر محیطی با \fB*\fP خاتمه یابد و بدون مقدار مشخص شود، پادمن محیط میزبان را برای متغیرهایی که با این پیشوند شروع می‌شوند جستجو کرده و آن متغیرها را به کانتینر اضافه می‌کند.

.PP
برای اولویت و مثال‌ها به بخش محیط مراجعه کنید.

.SS \fB--env-file\fP=\fIfile\fP
خواندن یک فایل حاوی متغیرهای محیطی با جداکننده خط.

.PP
برای اولویت و مثال‌ها به بخش محیط مراجعه کنید.

.SS \fB--env-host\fP
استفاده از محیط میزبان در داخل کانتینر. برای اولویت به بخش محیط مراجعه کنید. (این گزینه در کلاینت ریموت پادمن، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) در دسترس نیست)

.SS \fB--env-merge\fP=\fIenv\fP
پیش‌پردازش متغیرهای محیطی پیش‌فرض برای کانتینرها. برای مثال اگر ایمیج شامل متغیر محیطی \fBhello=world\fR باشد، کاربر می‌تواند با استفاده از \fB--env-merge hello=${hello}-some\fR آن را پیش‌پردازش کند تا مقدار جدید \fBhello=world-some\fR باشد.

.PP
لطفاً توجه داشته باشید که اگر متغیر محیطی \fBhello\fR در ایمیج وجود نداشته باشد، با یک رشته خالی جایگزین می‌شود و استفاده از \fB--env-merge hello=${hello}-some\fR منجر به مقدار جدید \fBhello=-some\fR خواهد شد (به علامت \fB-\fR در ابتدا دقت کنید).

.SS \fB--expose\fP=\fIport[/protocol]\fP
در دسترس قرار دادن یک پورت یا محدوده‌ای از پورت‌ها (مانند \fB--expose=3300-3310\fP).
پروتکل می‌تواند \fBtcp\fR، \fBudp\fR یا \fBsctp\fR باشد و در صورت عدم ارائه، \fBtcp\fR در نظر گرفته می‌شود. این گزینه با دستورالعمل EXPOSE برای ساخت ایمیج مطابقت دارد و هیچ تاثیری بر قوانین واقعی شبکه ندارد مگر اینکه از \fB-P/--publish-all\fP برای فوروارد به تمام پورت‌های در دسترس از پورت‌های تصادفی میزبان استفاده شود. برای فوروارد پورت‌های خاص از میزبان به درون کانتینر، از گزینه \fB-p/--publish\fP استفاده کنید.

.SS \fB--gidmap\fP=\fI[flags]container_gid:from_gid[:amount]\fP
اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت GID ارائه‌شده. این گزینه با گزینه‌های \fB--userns\fP و \fB--subgidname\fP تداخل دارد. این گزینه روشی برای نگاشت GIDهای میزبان به GIDهای کانتینر فراهم می‌کند، همانند نگاشت UIDهای میزبان به UIDهای کانتینر در \fB--uidmap\fP. برای جزئیات به \fB--uidmap\fP مراجعه کنید.

.PP
نکته: گزینه \fB--gidmap\fP نمی‌تواند همراه با گزینه \fB--pod\fP فراخوانی شود، زیرا هنگام حضور در یک پاد نمی‌توان یک gidmap را در سطح کانتینر تنظیم کرد.

.SS \fB--gpus\fP=\fIENTRY\fP
شروع کانتینر با پشتیبانی از GPU. که در آن \fBENTRY\fR می‌تواند \fBall\fR برای درخواست همه GPUها یا یک شناسه ویژه سازنده باشد. در حال حاضر دستگاه‌های NVIDIA و AMD پشتیبانی می‌شوند. اگر هر دو دستگاه‌های NVIDIA و AMD وجود داشته باشند، دستگاه‌های NVIDIA اولویت خواهند داشت، و باید یک نام دستگاه CDI با استفاده از پرچم \fB--device\fR مشخص شود تا مجموعه‌ای از GPUها از یک سازنده خاص درخواست شود.

.SS \fB--group-add\fP=\fIgroup\fP | \fIkeep-groups\fP
اختصاص گروه‌های اضافی به کاربر اصلی که درون فرایند کانتینر اجرا می‌شود.
.IP \(bu 2
\fBkeep-groups\fR یک پرچم ویژه است که به پادمن دستور می‌دهد دسترسی گروه‌های تکمیلی را حفظ کند.

.PP
به کانتینر اجازه می‌دهد از دسترسی گروه‌های تکمیلی کاربر استفاده کند. اگر سیستم‌فایل‌ها یا دستگاه‌ها فقط توسط گروه کاربر بدون ریشه قابل دسترسی باشند، این پرچم به زمان اجرای OCI دستور می‌دهد تا دسترسی گروه را به داخل کانتینر منتقل کند. در حال حاضر تنها با زمان اجرای OCI به نام \fBcrun\fR در دسترس است. نکته: \fBkeep-groups\fR انحصاری است و گروه‌های دیگر را نمی‌توان با این پرچم مشخص کرد. (برای دستورات راه دور، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) در دسترس نیست)

.SS \fB--group-entry\fP=\fIENTRY\fP
سفارشی‌سازی ورودی نوشته‌شده در فایل \fB/etc/group\fR درون کانتینر هنگام استفاده از \fB--user\fR.

.PP
متغیرهای $GROUPNAME، $GID و $USERLIST در زمان اجرا به طور خودکار با مقدار خود جایگزین می‌شوند.

.SS \fB--health-cmd\fP=\fI"command"\fP | \fI\&'["command", "arg1", ...]'\fP
تنظیم یا تغییر دستور بررسی سلامت برای یک کانتینر. این دستور برای ارزیابی سلامت کانتینر درون آن اجرا می‌شود. وجود این دستور برای اعمال سایر گزینه‌های بررسی سلامت الزامی است. مقدار \fBnone\fP بررسی‌های سلامت موجود را غیرفعال می‌کند.

.PP
چندین گزینه را می‌توان در قالب یک آرایه JSON ارسال کرد؛ در غیر این صورت دستور به عنوان یک آرگومان برای \fB/bin/sh -c\fP تفسیر می‌شود.

.PP
نکته: حتی در صورت پیکربندی بررسی سلامت در ایمیج، مقادیر پیش‌فرض استفاده می‌شوند.

.SS \fB--health-interval\fP=\fIinterval\fP
تنظیم بازه زمانی برای بررسی‌های سلامت. بازه زمانی \fBdisable\fP منجر به عدم تنظیم زمان‌سنج خودکار می‌شود. پیش‌فرض \fB30s\fP است.

.PP
نکته: این پارامتر پیکربندی مربوط به بررسی سلامت از ایمیج را بازنویسی می‌کند.

.SS \fB--health-log-destination\fP=\fIdirectory_path\fP
تنظیم مقصد گزارش HealthCheck. مسیر دایرکتوری، local یا events_logger (حالت local از فایل وضعیت کانتینر استفاده می‌کند) (پیش‌فرض: local).
.IP \(bu 2
\fBlocal\fR: (پیش‌فرض) گزارش‌های بررسی سلامت در کانتینرهای اورلی ذخیره می‌شوند (برای مثال: \fB$runroot/healthcheck.log\fR).
.IP \(bu 2
\fBdirectory\fR: یک فایل گزارش با نام \fB<container-ID>-healthcheck.log\fR با گزارش‌های بررسی سلامت در دایرکتوری مشخص‌شده ایجاد می‌کند.
.IP \(bu 2
\fBevents_logger\fR: لاگ با سازوکار لاگ‌گیری تنظیم‌شده توسط events_logger نوشته خواهد شد. همچنین برای بهبود کارایی در سیستمی با تعداد گزارش‌های زیاد، لاگ در یک دایرکتوری پیش‌فرض ذخیره می‌شود.

.SS \fB--health-max-log-count\fP=\fInumber of stored logs\fP
تنظیم حداکثر تعداد تلاش‌ها در فایل گزارش بررسی سلامت (مقدار '0' به معنای تعداد نامحدود تلاش‌ها در فایل گزارش است) (پیش‌فرض: 5 تلاش).

.SS \fB--health-max-log-size\fP=\fIsize of stored logs\fP
تنظیم حداکثر طول گزارش ذخیره‌شده بررسی سلامت بر حسب نویسه (مقدار "0" به معنای طول گزارش نامحدود است) (پیش‌فرض: 500 نویسه).

.SS \fB--health-on-failure\fP=\fIaction\fP
اقدامی که پس از انتقال کانتینر به وضعیت ناسالم انجام می‌شود. پیش‌فرض \fBnone\fP است.
.IP \(bu 2
\fBnone\fP: هیچ اقدامی انجام نده.
.IP \(bu 2
\fBkill\fP: کانتینر را متوقف (kill) کن.
.IP \(bu 2
\fBrestart\fP: کانتینر را مجدداً راه‌اندازی کن. اقدام \fBrestart\fR را با پرچم \fB--restart\fR ترکیب نکنید. هنگام اجرا درون یک واحد systemd، استفاده از اقدام \fBkill\fR یا \fBstop\fR را در نظر بگیرید تا از سیاست راه‌اندازی مجدد systemd استفاده شود.
.IP \(bu 2
\fBstop\fP: کانتینر را متوقف (stop) کن.

.SS \fB--health-retries\fP=\fIretries\fP
تعداد دفعات تکرار مجاز قبل از اینکه یک بررسی سلامت ناسالم تلقی شود. مقدار پیش‌فرض \fB3\fP است.

.PP
نکته: این پارامتر می‌تواند پیکربندی بررسی سلامت از ایمیج را بازنویسی کند.

.SS \fB--health-start-period\fP=\fIperiod\fP
زمان مقداردهی اولیه مورد نیاز برای بوت‌استرپ کانتینر. مقدار را می‌توان در قالب زمان مانند \fB2m3s\fP بیان کرد. مقدار پیش‌فرض \fB0s\fP است.

.PP
نکته: دستور بررسی سلامت به محض راه‌اندازی کانتینر اجرا می‌شود؛ اگر بررسی موفقیت‌آمیز باشد وضعیت سلامت کانتینر به \fBhealthy\fR به‌روزرسانی می‌شود. با این حال اگر ناموفق باشد، وضعیت سلامت تا زمان موفقیت بررسی یا پایان یافتن زمان \fB--health-start-period\fR در حالت \fBstarting\fR باقی می‌ماند. اگر دستور بررسی سلامت پس از اتمام زمان \fB--health-start-period\fR ناموفق شود، وضعیت به \fBunhealthy\fR تغییر می‌یابد. دستور بررسی سلامت به صورت دوره‌ای بر اساس مقدار \fB--health-interval\fR اجرا می‌شود.

.PP
نکته: این پارامتر پیکربندی مربوط به بررسی سلامت از ایمیج را بازنویسی خواهد کرد.

.SS \fB--health-startup-cmd\fP=\fI"command"\fP | \fI\&'["command", "arg1", ...]'\fP
تنظیم دستور بررسی سلامت آغازین (startup) برای کانتینر. این دستور درون کانتینر اجرا می‌شود و به عنوان گیت بررسی سلامت عادی عمل می‌کند. هنگامی که دستور آغازین موفق شود، بررسی سلامت عادی آغاز شده و بررسی آغازین متوقف می‌شود. به صورت اختیاری، اگر دستور تعداد دفعات مشخصی ناموفق شود، کانتینر مجدداً راه‌اندازی می‌گردد. بررسی سلامت آغازین را می‌توان به کار برد تا اطمینان حاصل شود کانتینرهایی با دوره راه‌اندازی طولانی تا پیش از شروع کامل ناسالم علامت‌گذاری نشوند. بررسی سلامت آغازین تنها زمانی قابل استفاده است که بررسی سلامت عادی (از ایمیج یا گزینه \fB--health-cmd\fR) نیز تنظیم شده باشد.

.SS \fB--health-startup-interval\fP=\fIinterval\fP
تنظیم بازه زمانی برای بررسی سلامت آغازین. بازه زمانی \fBdisable\fP منجر به عدم تنظیم زمان‌سنج خودکار می‌شود. پیش‌فرض \fB30s\fP است.

.SS \fB--health-startup-retries\fP=\fIretries\fP
تعداد تلاش‌های مجاز قبل از اینکه بررسی سلامت آغازین کانتینر را مجدداً راه‌اندازی کند. اگر روی \fB0\fP تنظیم شود، کانتینر هرگز ری‌استارت نمی‌شود. پیش‌فرض \fB0\fP است.

.SS \fB--health-startup-success\fP=\fIretries\fP
تعداد اجراهای موفق مورد نیاز قبل از اینکه بررسی سلامت آغازین موفق تلقی شود و بررسی سلامت عادی شروع گردد. مقدار \fB0\fP به معنای آن است که هر موفقیتی بررسی سلامت عادی را آغاز می‌کند. پیش‌فرض \fB0\fP است.

.SS \fB--health-startup-timeout\fP=\fItimeout\fP
حداکثر زمانی که دستور بررسی سلامت آغازین برای تکمیل فرصت دارد قبل از اینکه ناموفق تلقی شود. مقدار را می‌توان در قالب زمان مانند \fB2m3s\fP بیان کرد. پیش‌فرض \fB30s\fP است.

.SS \fB--health-timeout\fP=\fItimeout\fP
حداکثر زمان مجاز برای تکمیل بررسی سلامت قبل از اینکه یک بازه ناموفق تلقی شود. همانند start-period، مقدار می‌تواند در قالبی مانند \fB1m22s\fP بیان شود. مقدار پیش‌فرض \fB30s\fP است.

.PP
نکته: اتمام مهلت زمانی بررسی سلامت را ناموفق تلقی می‌کند. اگر دستور بررسی سلامت طولانی‌تر از \fItimeout\fP مشخص‌شده اجرا شود، سیگنال \fBSIGKILL\fR برای آن ارسال خواهد شد.

.PP
نکته: این پارامتر پیکربندی مربوط به بررسی سلامت از ایمیج را بازنویسی می‌کند.

.SS \fB--help\fP
چاپ راهنمای استفاده از دستور.

.SS \fB--hostname\fP, \fB-h\fP=\fIname\fP
تنظیم نام میزبان (hostname) درون کانتینر.

.PP
این گزینه تنها با فضای نام UTS خصوصی \fB--uts=private\fR (پیش‌فرض) قابل استفاده است. اگر \fB--pod\fR داده شود و پاد فضای نام UTS یکسانی را به اشتراک بگذارد (پیش‌فرض)، نام میزبان پاد استفاده می‌شود. نام میزبان داده‌شده همچنین با استفاده از نشانی IP اصلی کانتینر به فایل \fB/etc/hosts\fR اضافه می‌شود (گزینه \fB--add-host\fP را نیز ببینید).

.PP
هنگامی که \fB--hostname\fP استفاده نشود و کانتینر از فضای نام UTS خصوصی استفاده کند (پیش‌فرض)، پادمن نام میزبان را روی ۱۲ نویسه اول شناسه کانتینر تنظیم می‌کند. نام کانتینر اختصاص‌یافته با \fB--name\fP استفاده نمی‌شود مگر اینکه \fIcontainer_name_as_hostname=true\fP در \fBcontainers.conf\fR تنظیم شده باشد.

.PP
سامانه DNS شبکه پادمن نام کانتینر، شناسه کوتاه کانتینر (۱۲ نویسه اول) و هر \fB--hostname\fP مشخص‌شده را به عنوان نام‌های DNS ثبت می‌کند. نام میزبان پیش‌فرض با شناسه کوتاه مطابقت دارد. \fBpodman-network(1)\fP را ببینید.

.SS \fB--hosts-file\fP=\fIpath\fP | \fInone\fP | \fIimage\fP
فایل پایه برای ایجاد فایل \fB/etc/hosts\fR درون کانتینر. این باید یا یک مسیر مطلق به یک فایل روی سیستم میزبان باشد، یا یکی از پرچم‌های ویژه زیر:
  "" از پیکربندی \fBbase_hosts_file\fR در \fIcontainers.conf\fP پیروی می‌کند (پیش‌فرض)
  \fBnone\fR از فایل پایه استفاده نمی‌کند (یعنی با یک فایل خالی شروع می‌کند)
  \fBimage\fR از فایل \fB/etc/hosts\fR ایمیج کانتینر به عنوان فایل پایه استفاده می‌کند

.SS \fB--hostuser\fP=\fIname\fP
افزودن یک حساب کاربری به etc/passwd/ از میزبان به کانتینر. نام کاربری یا UID باید روی سیستم میزبان وجود داشته باشد.

.SS \fB--http-proxy\fP
به طور پیش‌فرض در صورت تنظیم بودن برای فرایند پادمن، متغیرهای محیطی پراکسی به کانتینر منتقل می‌شوند. این قابلیت را می‌توان با تنظیم مقدار روی \fBfalse\fP غیرفعال کرد. متغیرهای محیطی منتقل‌شده شامل \fBhttp_proxy\fP، \fBhttps_proxy\fP، \fBftp_proxy\fP، \fBno_proxy\fP و نسخه‌های حروف بزرگ آن‌ها هستند. این گزینه تنها زمانی لازم است که سیستم میزبان باید از پراکسی استفاده کند اما کانتینر نباید از پراکسی استفاده کند. متغیرهای محیطی پراکسی مشخص‌شده برای کانتینر به هر روش دیگری مقادیر منتقل‌شده از میزبان را بازنویسی می‌کنند. (سایر روش‌های تعیین پراکسی برای کانتینر شامل ارسال مقادیر با پرچم \fB--env\fP یا تنظیم متغیرها در زمان ساخت ایمیج است.)
هنگام استفاده با کلاینت ریموت، از متغیرهای محیطی پراکسی تنظیم‌شده روی فرایند سرور استفاده می‌کند.

.PP
پیش‌فرض \fBtrue\fP است.

.SS \fB--image-volume\fP=\fBbind\fP | \fItmpfs\fP | \fIignore\fP
به پادمن می‌گوید که چگونه با حجم‌های درون‌ساخت ایمیج برخورد کند. پیش‌فرض \fBbind\fP است.
.IP \(bu 2
\fBbind\fP: یک حجم نام‌گذاری‌شده ناشناس ایجاد شده و درون کانتینر مانت می‌شود.
.IP \(bu 2
\fBtmpfs\fP: حجم به عنوان tmpfs روی کانتینر مانت می‌شود که به کاربران اجازه می‌دهد محتوایی ایجاد کنند که پس از توقف کانتینر ناپدید می‌شود.
.IP \(bu 2
\fBignore\fP: تمامی حجم‌ها نادیده گرفته می‌شوند و اقدامی صورت نمی‌گیرد.

.SS \fB--init\fP
اجرای یک init درون کانتینر که سیگنال‌ها را فوروارد کرده و فرایندهای زامبی را جمع‌آوری (reap) می‌کند. باینری container-init در مسیر \fB/run/podman-init\fR مانت می‌شود. مانت کردن روی \fB/run\fR اجرای کانتینر را مختل می‌کند.

.SS \fB--init-path\fP=\fIpath\fP
مسیر به باینری container-init.

.SS \fB--interactive\fP, \fB-i\fP
هنگامی که روی \fBtrue\fP تنظیم شود، stdin را برای فرایند درون کانتینر در دسترس قرار می‌دهد. اگر \fBfalse\fP باشد، stdin فرایند درون کانتینر خالی بوده و بلافاصله بسته می‌شود.

.PP
اگر کانتینر متصل باشد (attached)، ورودی استاندارد (stdin) به فرایند کانتینر پایپ می‌شود. اگر جدا باشد (detached)، خواندن stdin تا زمان اتصال بعدی مسدود (block) خواهد شد.

.PP
هشدار: پادمن ورودی را از stdin به محض در دسترس قرار گرفتن مصرف می‌کند، حتی اگر فرایند درون کانتینر درخواستی برای آن نکرده باشد.

.SS \fB--ip\fP=\fIIPv4\fP
تعیین یک نشانی IPv4 استاتیک برای کانتینر، برای مثال \fB10.88.64.128\fP\&.
این گزینه تنها زمانی قابل استفاده است که کانتینر تنها به یک شبکه پیوسته باشد — یعنی \fB--network=network-name\fP حداکثر یک بار استفاده شده باشد — و کانتینر از طریق \fB--network=container:\fIid\fP\fP به فضای نام شبکه کانتینر دیگری ملحق نشده باشد. نشانی باید در محدوده استخر IP شبکه باشد (پیش‌فرض \fB10.88.0.0/16\fP).

.PP
برای تعیین چندین نشانی IP استاتیک به ازای هر کانتینر، از گزینه \fB--network\fP همراه با چندین مقدار \fBip\fR جداشده با کاما استفاده کنید:

.EX
--network mynet:ip=10.88.0.10,ip=10.88.0.11,ip=10.88.0.12
.EE

.PP
این کار چندین نشانی IPv4 استاتیک را به همان رابط شبکه اختصاص می‌دهد.

.PP
شبکه‌های چند زیرشبکه‌ای: هنگامی که یک شبکه دارای چندین زیرشبکه است، می‌توانید IPهایی از زیرشبکه‌های مختلف را به همان کانتینر اختصاص دهید. IPها روی یک رابط شبکه اعمال می‌شوند که IP اول به عنوان آدرس اصلی و IPهای بعدی به عنوان آدرس‌های ثانویه خواهند بود.

.PP
ترتیب تخصیص IP: برای شبکه‌های چند زیرشبکه‌ای، IPها بر اساس زیرشبکه مربوطه‌شان گروه‌بندی و مرتب می‌شوند، با پیروی از ترتیبی که زیرشبکه‌ها در طول ساخت شبکه (از طریق پرچم‌های \fB--subnet\fR) تعریف شده‌اند. ترتیبی که IPها را در دستور مشخص می‌کنید تاثیری بر ترتیب تخصیص نهایی ندارد. برای مثال:

.EX
podman network create --subnet 10.89.0.0/24 --subnet 10.90.0.0/24 mynet
podman run --network mynet:ip=10.90.0.20,ip=10.89.0.10,ip=10.89.0.11 alpine
.EE

.PP
منجر به IPهای مرتب‌شده بر اساس زیرشبکه می‌شود: \fB10.89.0.10\fP (اصلی)، \fB10.89.0.11\fP (ثانویه)، \fB10.90.0.20\fP (ثانویه)، زیرا \fB10.89.0.0/24\fP ابتدا تعریف شده بود.

.PP
تخصیص پویا: اگر تعداد IPهای مشخص‌شده کمتر از زیرشبکه‌های موجود باشد، زیرشبکه‌های باقی‌مانده IPهای تخصیص‌یافته به صورت پویا دریافت می‌کنند. IPهای پویا پس از اعمال تمام IPهای استاتیک به ترتیب زیرشبکه اختصاص می‌یابند.

.PP
مثال با شبکه چند زیرشبکه‌ای:

.EX
podman network create --subnet 10.89.0.0/24 --subnet 10.90.0.0/24 mynet
podman run --network mynet:ip=10.89.0.10,ip=10.90.0.20 alpine
.EE

.PP
این دستور \fBeth0\fP را با \fB10.89.0.10\fP (اصلی) و \fB10.90.0.20\fP (ثانویه) پیکربندی می‌کند.

.SS \fB--ip6\fP=\fIIPv6\fP
تعیین یک نشانی IPv6 استاتیک برای کانتینر، برای مثال \fBfd46:db93:aa76:ac37::10\fP\&.
این گزینه تنها زمانی قابل استفاده است که کانتینر تنها به یک شبکه پیوسته باشد — یعنی \fB--network=network-name\fP حداکثر یک بار استفاده شده باشد — و کانتینر از طریق \fB--network=container:\fIid\fP\fP به فضای نام شبکه کانتینر دیگری ملحق نشده باشد. نشانی باید درون استخر آدرس‌های IPv6 شبکه باشد.

.PP
برای تعیین چندین نشانی IPv6 استاتیک به ازای هر کانتینر، چندین شبکه را با استفاده از گزینه \fB--network\fP همراه با نشانی IPv6 استاتیک با استفاده از حالت \fBip6\fR برای آن گزینه تنظیم کنید.

.SS \fB--ipc\fP=\fIipc\fP
تنظیم حالت فضای نام IPC برای کانتینر. پیش‌فرض ایجاد یک فضای نام IPC خصوصی است.
.IP \(bu 2
"": استفاده از پیش‌فرض پادمن، تعریف‌شده در containers.conf.
.IP \(bu 2
\fBcontainer:\fP\fIid\fP: استفاده مجدد از حافظه اشتراکی، سمافورها و صف‌های پیام یک کانتینر دیگر.
.IP \(bu 2
\fBhost\fP: استفاده از حافظه اشتراکی، سمافورها و صف‌های پیام میزبان درون کانتینر. نکته: حالت host به کانتینر دسترسی کامل به حافظه اشتراکی محلی می‌دهد و بنابراین ناامن تلقی می‌شود.
.IP \(bu 2
\fBnone\fP: فضای نام IPC خصوصی، بدون مانت شدن dev/shm/.
.IP \(bu 2
\fBns:\fP\fIpath\fP: مسیر به فضای نام IPC برای پیوستن.
.IP \(bu 2
\fBprivate\fP: فضای نام IPC خصوصی.
.IP \(bu 2
\fBshareable\fP: فضای نام IPC خصوصی با امکان اشتراک‌گذاری آن با کانتینرهای دیگر.

.SS \fB--label\fP, \fB-l\fP=\fIkey=value\fP
افزودن فراداده (metadata) به یک کانتینر.

.SS \fB--label-file\fP=\fIfile\fP
خواندن یک فایل حاوی برچسب‌ها با جداکننده خط.

.SS \fB--link-local-ip\fP=\fIip\fP
پیاده‌سازی نشده است.

.SS \fB--log-driver\fP=\fIdriver\fP
درایور لاگ‌گیری برای کانتینر. گزینه‌های در دسترس فعلی عبارتند از \fBk8s-file\fP، \fBjournald\fP، \fBnone\fP، \fBpassthrough\fP و \fBpassthrough-tty\fP، که \fBjson-file\fP برای سازگاری اسکریپت‌ها نام مستعار \fBk8s-file\fP است (پیش‌فرض \fBjournald\fP).

.PP
دستور podman info در زیر درایور لاگ پیش‌فرض سیستم را نمایش می‌دهد:

.EX
$ podman info --format '{{ .Host.LogDriver }}'
journald
.EE

.PP
درایور \fBpassthrough\fP جریان‌های استاندارد (stdin, stdout, stderr) را به کانتینر منتقل می‌کند. این درایور در کلاینت ریموت پادمن، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) و روی tty مجاز نیست، زیرا در برابر حملات TIOCSTI آسیب‌پذیر است.

.PP
درایور \fBpassthrough-tty\fP مشابه \fBpassthrough\fP است به جز اینکه اگر کاربر واقعاً بخواهد اجازه استفاده از آن روی TTY را نیز می‌دهد.

.SS \fB--log-opt\fP=\fIname=value\fP
گزینه‌های اختصاصی درایور لاگ‌گیری.

.PP
پیکربندی سفارشی لاگ‌گیری را تنظیم می‌کند. نام‌های زیر پشتیبانی می‌شوند:

.PP
\fBpath\fP: تعیین مسیر به فایل گزارش
    (مانند \fB--log-opt path=/var/log/container/mycontainer.json\fP)؛

.PP
\fBmax-size\fP: تعیین حداکثر اندازه فایل گزارش
    (مانند \fB--log-opt max-size=10mb\fP)؛

.PP
\fBtag\fP: تعیین برچسب سفارشی لاگ برای کانتینر
    (مانند \fB--log-opt tag="{{.ImageName}}"\fP\&.
از کلیدهای مشابه با \fBpodman inspect --format\fP پشتیبانی می‌کند.
این گزینه در حال حاضر تنها توسط درایور لاگ \fBjournald\fP پشتیبانی می‌شود.)

.PP
\fBlabel\fP: تعیین برچسب سفارشی برای کانتینر
    (مانند \fB--log-opt label="CONTAINER_IMAGE={{.ImageName}}"\fP\&.
از کلیدهای مشابه با \fBpodman inspect --format\fP پشتیبانی می‌کند.
این گزینه می‌تواند چندین بار تکرار شود.
این گزینه در حال حاضر تنها توسط درایور لاگ \fBjournald\fP پشتیبانی می‌شود.)

.SS \fB--mac-address\fP=\fIaddress\fP
آدرس MAC رابط شبکه کانتینر (مانند 92:d0:c6:0a:29:33).
این گزینه تنها زمانی قابل استفاده است که کانتینر فقط به یک شبکه پیوسته باشد — یعنی \fB--network=\fInetwork-name\fP\fP حداکثر یک بار استفاده شده باشد —
و کانتینر از طریق \fB--network=container:\fIid\fP\fP به فضای نام شبکه کانتینر دیگری ملحق نشده باشد.

.PP
به یاد داشته باشید که آدرس MAC در یک شبکه اترنت باید یکتا باشد.
نشانی link-local در IPv6 بر اساس آدرس MAC دستگاه طبق RFC4862 تعیین می‌شود.

.PP
برای تعیین چندین نشانی MAC استاتیک به ازای هر کانتینر، چندین شبکه را با استفاده از گزینه \fB--network\fP همراه با نشانی MAC استاتیک با استفاده از حالت \fBmac\fR برای آن گزینه تنظیم کنید.

.SS \fB--memory\fP, \fB-m\fP=\fInumber[unit]\fP
محدودیت حافظه. یک واحد \fIunit\fP می‌تواند \fBb\fP (بایت)، \fBk\fP (کیبی‌بایت)، \fBm\fP (مبی‌بایت) یا \fBg\fP (گیبی‌بایت) باشد.

.PP
اجازه می‌دهد حافظه در دسترس یک کانتینر محدود شود. اگر میزبان از حافظه swap پشتیبانی کند، تنظیم حافظه \fB--memory\fP می‌تواند بزرگتر از RAM فیزیکی باشد. اگر محدودیت 0 مشخص شود (بدون استفاده از \fB--memory\fP)، حافظه کانتینر محدود نمی‌شود. حد واقعی ممکن است به مضربی از اندازه صفحه سیستم‌عامل گرد شود.

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--memory-reservation\fP=\fInumber[unit]\fP
محدودیت نرم حافظه (soft limit). یک واحد \fIunit\fP می‌تواند \fBb\fP (بایت)، \fBk\fP (کیبی‌بایت)، \fBm\fP (مبی‌بایت) یا \fBg\fP (گیبی‌بایت) باشد.

.PP
پس از تنظیم رزرو حافظه، هنگامی که سیستم رقابت برای حافظه یا کمبود حافظه را تشخیص دهد، کانتینرها مجبور می‌شوند مصرف خود را به اندازه رزرو خود محدود کنند. بنابراین همیشه مقدار را کمتر از \fB--memory\fP تنظیم کنید، در غیر این صورت محدودیت سخت اولویت خواهد داشت. به طور پیش‌فرض، رزرو حافظه برابر با محدودیت حافظه است.

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--memory-swap\fP=\fInumber[unit]\fP
مقدار محدودیتی برابر با حافظه به علاوه سواپ (swap).
یک واحد \fIunit\fP می‌تواند \fBb\fP (بایت)، \fBk\fP (کیبی‌بایت)، \fBm\fP (مبی‌بایت) یا \fBg\fP (گیبی‌بایت) باشد.

.PP
باید همراه با پرچم \fB-m\fP (\fB--memory\fP) استفاده شود.
مقدار آرگومان باید بزرگتر از مقدار \fB-m\fP (\fB--memory\fP) باشد. به طور پیش‌فرض، روی دو برابر مقدار \fB--memory\fP تنظیم می‌شود.

.PP
مقدار \fInumber\fP را روی \fB-1\fP تنظیم کنید تا swap نامحدود فعال شود.

.PP
این گزینه در سیستم‌های بدون ریشه با cgroups V1 پشتیبانی نمی‌شود.

.SS \fB--memory-swappiness\fP=\fInumber\fP
تنظیم رفتار swappiness حافظه کانتینر. یک عدد صحیح بین \fI0\fP و \fI100\fP را می‌پذیرد.

.PP
این پرچم تنها در سیستم‌های دارای ریشه با cgroups V1 پشتیبانی می‌شود.

.SS \fB--mount\fP=\fItype=TYPE,TYPE-SPECIFIC-OPTION[,...]\fP
اتصال یک مانت سیستم‌فایل به کانتینر.

.PP
انواع TYPEهای مانت پشتیبانی‌شده فعلی عبارتند از \fBartifact\fP، \fBbind\fP، \fBdevpts\fP، \fBglob\fP، \fBimage\fP، \fBramfs\fP، \fBtmpfs\fP و \fBvolume\fP\&.

.PP
گزینه‌های مشترک میان تمام انواع مانت:
.IP \(bu 2
\fIsrc\fP, \fIsource\fP: مشخصات منبع مانت برای \fBbind\fP، \fBglob\fP و \fBvolume\fP\&.
برای \fBartifact\fP، \fBbind\fP، \fBglob\fP و \fBimage\fP الزامی است.
برای \fBvolume\fP اختیاری است؛ در صورت حذف یک حجم ناشناس ایجاد می‌شود.
.IP \(bu 2
\fIdst\fP, \fIdest\fP, \fIdestination\fP, \fItarget\fP: مشخصات مقصد مانت.

.PP
هنگامی که الگوهای glob منبع بدون دایرکتوری مقصد مشخص شوند، فایل‌ها و پوشه‌ها با مسیر کاملشان در کانتینر مانت می‌شوند. هنگامی که مقصد مشخص شود، فایل‌ها و پوشه‌های منطبق با glob بر روی نام فایل پایه در دایرکتوری مقصد مانت می‌شوند. گزینه \fBtype=glob,src=/foo*,destination=/tmp/bar\fR به موتورهای کانتینر دستور می‌دهد تا فایل‌های میزبان منطبق با /foo* را در دایرکتوری /tmp/bar/ درون کانتینر مانت کنند.

.PP
گزینه‌های ویژه type=\fBartifact\fP:
.IP \(bu 2
\fIdigest\fP: اگر منبع آرتیفکت شامل چندین blob باشد، می‌توان یک دایجست تعیین کرد تا تنها همان blob مشخص‌شده با دایجست مانت شود.
.IP \(bu 2
\fItitle\fP: اگر منبع آرتیفکت شامل چندین blob باشد، می‌توان یک عنوان تنظیم کرد که با یادداشت \fBorg.opencontainers.image.title\fR مقایسه می‌شود.
.IP \(bu 2
\fIname\fP: این گزینه می‌تواند برای بازنویسی نام فایلی که در داخل کانتینر برای مانت استفاده می‌کنیم به کار رود. در یک آرتیفکت تک blob اگر \fIdst\fP یک دایرکتوری باشد نام همان‌طور که هست استفاده می‌شود و در غیر این صورت نادیده گرفته می‌شود. با یک آرتیفکت چند blob، نام با پسوند اندیس \fB<name>-x\fR استفاده خواهد شد که در آن x اندیس لایه در آرتیفکت با شروع از 0 است.

.PP
آرگومان \fIsrc\fP شامل نام آرتیفکت است که باید از قبل به صورت محلی وجود داشته باشد. آرگومان \fIdst\fP شامل مسیر هدف است؛ اگر مسیر در کانتینر یک دایرکتوری باشد، عنوان blob (یادداشت \fBorg.opencontainers.image.title\fR) به عنوان نام فایل استفاده شده و به مسیر متصل می‌شود. اگر یادداشت وجود نداشته باشد، از دایجست به عنوان نام فایل استفاده می‌شود. این امر منجر به مانت شدن تمامی blobهای آرتیفکت در مسیر داده‌شده در کانتینر می‌شود.

.PP
با این حال اگر مسیر \fIdst\fP یک فایل موجود در کانتینر باشد، blob مستقیماً روی آن مانت خواهد شد. این تنها زمانی کار می‌کند که آرتیفکت شامل یک blob تکی باشد یا \fIdigest\fP یا \fItitle\fP مشخص شده باشد.

.PP
اگر مسیر \fIdst\fP از قبل در کانتینر وجود نداشته باشد، در صورتی که آرتیفکت شامل یک blob باشد رفتاری مانند حالت فایل موجود خواهد داشت و مستقیماً در آن مسیر مانت می‌شود. اگر بیش از یک blob داشته باشد مانند حالت دایرکتوری موجود عمل کرده و هر blob را به عنوان یک فایل درون مسیر \fIdst\fP مانت می‌کند.

.PP
گزینه‌های ویژه type=\fBvolume\fP:
.IP \(bu 2
\fIro\fP, \fIreadonly\fP: به صورت \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP).
.IP \(bu 2
\fIU\fP, \fIchown\fP: به صورت \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP). تغییر بازگشتی مالک و گروه حجم منبع بر اساس UID و GID کانتینر.
.IP \(bu 2
\fIsubpath\fP: مانت کردن تنها یک مسیر فرعی مشخص درون حجم، به جای کل حجم.
.IP \(bu 2
\fIrelabel\fP: به صورت \fIshared\fP، \fIprivate\fP\&. پیمایش بازگشتی مانت و تنظیم برچسب سیستم امنیتی (مانند SELinux) روی هر فایل برای اعطای دسترسی از بستر کانتینر.
مقدار \fIshared\fP برچسبی اعمال می‌کند که دسترسی را به تمام کانتینرها می‌دهد، در حالی که \fIprivate\fP برچسبی اعمال می‌کند که دسترسی را به این کانتینر خاص اعطا می‌نماید.
.IP \(bu 2
\fIz\fP, \fIZ\fP: حالت خلاصه‌شده به ترتیب برای \fIrelabel=shared\fP و \fIrelabel=private\fP.
.IP \(bu 2
\fIidmap\fP: در صورت تعیین، یک مانت با نگاشت شناسه (idmapped) به فضای نام کاربری هدف در کانتینر ایجاد می‌کند.
گزینه idmap تنها توسط پادمن در حالت rootful پشتیبانی می‌شود. کرنل لینوکس استفاده از سیستم‌های فایل دارای نگاشت شناسه را برای کاربران غیرمجاز مجاز نمی‌داند.
گزینه idmap از یک نگاشت سفارشی پشتیبانی می‌کند که می‌تواند با فضای نام کاربری مورد استفاده کانتینر متفاوت باشد.
نگاشت را می‌توان بعد از گزینه idmap به صورت: \fBidmap=uids=0-1-10#10-11-10;gids=0-100-10\fR مشخص کرد. برای هر سه‌گانه، مقدار اول
شروع شناسه‌های سیستم‌فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم داده می‌شود.
محدوده‌های متعدد با # جدا می‌شوند. اگر نگاشت مشخص‌شده با '@' آغاز شود، نگاشت نسبت به فضای نام کاربری کانتینر
در نظر گرفته می‌شود. شناسه میزبان برای نگاشت تغییر می‌یابد تا موقعیت نسبی کاربر کانتینر در فضای نام کاربری کانتینر لحاظ شود.

.PP
گزینه‌های ویژه type=\fBimage\fP:
.IP \(bu 2
\fIrw\fP, \fIreadwrite\fP: به صورت \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP).
.IP \(bu 2
\fIsubpath\fP: مانت کردن تنها یک مسیر خاص درون ایمیج، به‌جای کل ایمیج.

.PP
گزینه‌های ویژه \fBbind\fP و \fBglob\fP:
.IP \(bu 2
\fIro\fP, \fIreadonly\fP: به صورت \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP).
.IP \(bu 2
\fIbind-propagation\fP: به صورت \fIshared\fP، \fIslave\fP، \fIprivate\fP، \fIunbindable\fP، \fIrshared\fP، \fIrslave\fP، \fIrunbindable\fP یا \fBrprivate\fP (پیش‌فرض).[1]
\[la]#Footnote1\[ra] همچنین mount(2) را ببینید.
.IP \(bu 2
\fIbind-nonrecursive\fP: ایجاد نکردن یک bind mount بازگشتی. به طور پیش‌فرض بازگشتی است.
.IP \(bu 2
\fIrelabel\fP: به صورت \fIshared\fP، \fIprivate\fP\&. پیمایش بازگشتی مانت و تنظیم برچسب سیستم امنیتی (مانند SELinux) روی هر فایل برای اعطای دسترسی از بستر کانتینر.
مقدار \fIshared\fP برچسبی اعمال می‌کند که دسترسی را به تمام کانتینرها می‌دهد، در حالی که \fIprivate\fP برچسبی اعمال می‌کند که دسترسی را به این کانتینر خاص اعطا می‌نماید.
.IP \(bu 2
\fIz\fP, \fIZ\fP: حالت خلاصه‌شده به ترتیب برای \fIrelabel=shared\fP و \fIrelabel=private\fP.
.IP \(bu 2
\fIidmap\fP: در صورت تعیین، یک مانت با نگاشت شناسه (idmapped) به فضای نام کاربری هدف در کانتینر ایجاد می‌کند.
گزینه idmap تنها توسط پادمن در حالت rootful پشتیبانی می‌شود. کرنل لینوکس استفاده از سیستم‌های فایل دارای نگاشت شناسه را برای کاربران غیرمجاز مجاز نمی‌داند.
گزینه idmap از یک نگاشت سفارشی پشتیبانی می‌کند که می‌تواند با فضای نام کاربری مورد استفاده کانتینر متفاوت باشد.
نگاشت را می‌توان بعد از گزینه idmap به صورت: \fBidmap=uids=0-1-10#10-11-10;gids=0-100-10\fR مشخص کرد. برای هر سه‌گانه، مقدار اول
شروع شناسه‌های سیستم‌فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم داده می‌شود.
محدوده‌های متعدد با # جدا می‌شوند. اگر نگاشت مشخص‌شده با '@' آغاز شود، نگاشت نسبت به فضای نام کاربری کانتینر
در نظر گرفته می‌شود. شناسه میزبان برای نگاشت تغییر می‌یابد تا موقعیت نسبی کاربر کانتینر در فضای نام کاربری کانتینر لحاظ شود.
.IP \(bu 2
\fIU\fP, \fIchown\fP: به صورت \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP). تغییر بازگشتی مالک و گروه حجم منبع بر اساس UID و GID کانتینر.
.IP \(bu 2
\fIno-dereference\fP: ارجاع نگرفتن از symlinkها، بلکه کپی کردن منبع پیوند به مقصد مانت.

.PP
گزینه‌های ویژه type=\fBtmpfs\fP و \fBramfs\fP:
.IP \(bu 2
\fIro\fP, \fIreadonly\fP: به صورت \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP).
.IP \(bu 2
\fItmpfs-size\fP: اندازه مانت tmpfs/ramfs بر حسب بایت. در لینوکس به طور پیش‌فرض نامحدود است.
.IP \(bu 2
\fItmpfs-mode\fP: حالت هشت‌هشتی (octal) فایل برای tmpfs/ramfs (مانند 700 یا 0700).
.IP \(bu 2
\fItmpcopyup\fP: فعال‌سازی copyup از دایرکتوری ایمیج در همان مکان به tmpfs/ramfs. به صورت پیش‌فرض استفاده می‌شود.

.PP
هنگامی که مقصد tmpfs درون یک حجم یا bind mount باشد، فایل‌های مانت والد نیز در tmpfs کپی می‌شوند، بنابراین محتوای والد قابل مشاهده باقی می‌ماند. از \fBnotmpcopyup\fP برای مانت یک tmpfs خالی استفاده کنید که زیردرخت مانت والد را پوشش می‌دهد.
.IP \(bu 2
\fInoatime\fP: غیرفعال کردن به‌روزرسانی زمان دسترسی فایل هنگام خواندن فایل.
.IP \(bu 2
\fInotmpcopyup\fP: غیرفعال کردن کپی فایل‌ها از ایمیج به tmpfs/ramfs.

.PP
هنگام مانت کردن tmpfs درون یک حجم یا bind mount از این گزینه استفاده کنید تا اطمینان حاصل شود که tmpfs به درستی زیردرخت مانت والد را پوشش می‌دهد.
.IP \(bu 2
\fIU\fP, \fIchown\fP: به صورت \fItrue\fP یا \fIfalse\fP (پیش‌فرض در صورت عدم تعیین: \fIfalse\fP). تنظیم گزینه‌های uid و gid برای سیستم‌فایل tmpfs بر اساس UID و GID کانتینر. این گزینه بازگشتی \fBنیست\fP.

.PP
گزینه‌های ویژه type=\fBdevpts\fP:
.IP \(bu 2
\fIuid\fP: مقدار عددی UID مالک فایل (پیش‌فرض: 0).
.IP \(bu 2
\fIgid\fP: مقدار عددی GID مالک فایل (پیش‌فرض: 0).
.IP \(bu 2
\fImode\fP: ماسک مجوز هشت‌هشتی برای فایل (پیش‌فرض: 600).
.IP \(bu 2
\fImax\fP: حداکثر تعداد PTYها (پیش‌فرض: 1048576).

.PP
مثال‌ها:
.IP \(bu 2
\fBtype=bind,source=/path/on/host,destination=/path/in/container\fR
.IP \(bu 2
\fBtype=bind,src=/path/on/host,dst=/path/in/container,relabel=shared\fR
.IP \(bu 2
\fBtype=bind,src=/path/on/host,dst=/path/in/container,relabel=shared,U=true\fR
.IP \(bu 2
\fBtype=bind,src=/path/on/host,dst=/path/in/container,idmap\fR
.IP \(bu 2
\fBtype=bind,src=/path/on/host,dst=/path/in/container,idmap=uids=0-1-10;gids=0-100-10\fR
.IP \(bu 2
\fBtype=devpts,destination=/dev/pts\fR
.IP \(bu 2
\fBtype=glob,src=/usr/lib/libfoo*,destination=/usr/lib,ro=true\fR
.IP \(bu 2
\fBtype=image,source=fedora,destination=/fedora-image,rw=true\fR
.IP \(bu 2
\fBtype=ramfs,tmpfs-size=512M,destination=/path/in/container\fR
.IP \(bu 2
\fBtype=tmpfs,tmpfs-size=512M,destination=/path/in/container\fR
.IP \(bu 2
\fBtype=tmpfs,destination=/path/in/container,noswap\fR
.IP \(bu 2
\fBtype=artifact,src=quay.io/libpod/testartifact:20250206-single,dst=/data\fR
.IP \(bu 2
\fBtype=artifact,src=quay.io/libpod/testartifact:20250206-multi,dst=/data,title=test1\fR
.IP \(bu 2
\fBtype=volume,destination=/path/in/container\fR
.IP \(bu 2
\fBtype=volume,src=test_vol,dst=/data,subpath=/code/docs\fR

.SS \fB--name\fP=\fIname\fP
.SS \fB--name\fP=\fIname\fP
اختصاص یک نام به کانتینر.

.PP
مجری می‌تواند یک کانتینر را به سه روش شناسایی کند:
.IP \(bu 2
شناسه طولانی UUID (مانند “f78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778”)؛
.IP \(bu 2
شناسه کوتاه UUID (مانند “f78375b1c487”)؛
.IP \(bu 2
نام (مانند “jonah”).

.PP
پادمن یک UUID برای هر کانتینر ایجاد می‌کند، و اگر هیچ نامی با استفاده از \fB--name\fP به کانتینر اختصاص داده نشود، پادمن یک نام تصادفی مانند \fBexciting_chebyshev\fR (صفت_اسم، سازگار با داکر) تولید می‌کند. الزامی نیست که نام کانتینرها نام‌های میزبان یا دامنه‌های معتبر باشند. زیرخط‌ها و نویسه‌های دیگری که طبق قوانین نام‌گذاری مجاز هستند پذیرفته می‌شوند. در شبکه‌های پادمن با DNS فعال، تحلیل نام کانتینر به کانتینر همچنان از نام داده‌شده استفاده می‌کند، برای مثال \fBexciting_chebyshev\fR\&. این نام به عنوان روشی انسان‌دوستانه‌تر برای شناسایی کانتینرها مفید است. این ویژگی هم برای کانتینرهای پس‌زمینه و هم پیش‌زمینه کار می‌کند.
نام کانتینر همچنین با استفاده از نشانی IP اصلی کانتینر به فایل \fB/etc/hosts\fR اضافه می‌شود (گزینه \fB--add-host\fP را نیز ببینید).

.PP
نام کانتینر همان نام میزبان درون کانتینر نیست؛ به \fB--hostname\fP مراجعه کنید. برای اطلاعات بیشتر درباره DNS شبکه به \fBpodman-network(1)\fP مراجعه نمایید.

.SS \fB--network\fP=\fImode\fP, \fB--net\fP
تنظیم حالت شبکه برای کانتینر.

.PP
مقادیر مجاز \fImode\fP عبارتند از:
.IP \(bu 2
\fBbridge[:OPTIONS,...]\fP: ایجاد یک پشته شبکه روی پل پیش‌فرض. این پیش‌فرض کانتینرهای rootful است. گزینه‌های اضافی زیر را می‌توان مشخص کرد:
.RS
.IP \(bu 2
\fBalias=\fP\fIname\fP: افزودن نام مستعار در سطح شبکه برای کانتینر.
.IP \(bu 2
\fBip=\fP\fIIPv4\fP: تعیین نشانی IPv4 استاتیک برای این کانتینر.
.IP \(bu 2
\fBip6=\fP\fIIPv6\fP: تعیین نشانی IPv6 استاتیک برای این کانتینر.
.IP \(bu 2
\fBmac=\fP\fIMAC\fP: تعیین نشانی MAC استاتیک برای این کانتینر.
.IP \(bu 2
\fBinterface_name=\fP\fIname\fP: تعیین نام رابط شبکه ایجادشده درون کانتینر.
.IP \(bu 2
\fBhost_interface_name=\fP\fIname\fP: تعیین نام رابط شبکه ایجادشده بیرون کانتینر.
.RE
.IP
سایر گزینه‌ها بدون اعتبارسنجی به netavark منتقل می‌شوند که برای ارسال آرگومان به افزونه‌های netavark مفید است.

برای شبکه‌های پل بدون ریشه، فورواردینگ پورت به طور پیش‌فرض از \fBrootlessport\fR استفاده می‌کند. تنظیم \fBrootless_port_forwarder="pasta"\fR در بخش \fB[network]\fR فایل \fBcontainers.conf(5)\fP فورواردینگ را به سطح کرنل pasta (از طریق \fBpesto\fR) تغییر می‌دهد که نشانی IP مبدا مشتری را درون کانتینر حفظ می‌کند. این گزینه آزمایشی است و رفتار آن ممکن است تغییر کند.

برای مثال، جهت تنظیم نشانی IPv4 و آدرس MAC استاتیک، از \fB--network bridge:ip=10.88.0.10,mac=44:33:22:11:00:99\fR استفاده کنید.
.IP \(bu 2
\fI<network name or ID>\fP\fB[:OPTIONS,...]\fP: اتصال به یک شبکه تعریف‌شده توسط کاربر؛ این نام یا شناسه شبکه‌ای است که با \fBpodman network create\fP ساخته شده است. می‌توان همان گزینه‌های توضیح‌داده‌شده در حالت bridge بالا را مشخص کرد. از گزینه \fB--network\fP چندین بار برای مشخص کردن شبکه‌های بیشتر استفاده کنید.
.br
برای سازگاری با نسخه‌های قبلی، می‌توان شبکه‌های جداشده با کاما را در آرگومان اول \fB--network\fP مشخص کرد، با این حال این کار مانع از استفاده از گزینه‌های بخش bridge بالا می‌شود.
.IP \(bu 2
\fBnone\fP: ایجاد فضای نام شبکه بدون پیکربندی رابط‌های شبکه، بنابراین کانتینر فاقد اتصال شبکه خواهد بود.
.IP \(bu 2
\fBcontainer:\fP\fIid\fP: استفاده مجدد از پشته شبکه یک کانتینر دیگر.
.IP \(bu 2
\fBhost\fP: استفاده از فضای نام شبکه میزبان برای کانتینر به جای ایجاد یک فضای نام ایزوله. هشدار: این گزینه به کانتینر دسترسی کامل به سوکت‌های انتزاعی دامین یونیکس و سوکت‌های TCP/UDP متصل به localhost را می‌دهد و استفاده از آن ممکن است مخاطره امنیتی تلقی شود.
.IP \(bu 2
\fBns:\fP\fIpath\fP: مسیر به فضای نام شبکه برای پیوستن.
.IP \(bu 2
\fBprivate\fP: ایجاد یک فضای نام جدید برای کانتینر. این حالت از \fBbridge\fP برای کانتینرهای rootful و از \fBpasta\fP برای rootless استفاده می‌کند.
.IP \(bu 2
\fBpasta[:OPTIONS,...]\fP: استفاده از \fBpasta\fP(1) برای ایجاد یک پشته شبکه در حالت کاربر (user-mode).
.br
این حالت پیش‌فرض برای کانتینرهای بدون ریشه است و تنها در حالت بدون ریشه پشتیبانی می‌شود.
.br
به طور پیش‌فرض، آدرس‌های IPv4 و IPv6 و مسیرها و همچنین نام رابط پاد از میزبان کپی می‌شوند. فوروارد پورت نشانی IP اصلی مبدا را حفظ می‌کند. گزینه‌های شرح‌داده‌شده در pasta(1) را می‌توان به صورت آرگومان‌های جداشده با کاما تعیین کرد.
.br
از نظر گزینه‌های pasta(1)، پرچم \fB--config-net\fP به صورت پیش‌فرض داده می‌شود تا هنگام راه‌اندازی کانتینر شبکه پیکربندی شود، و \fB--no-map-gw\fP نیز برای اجتناب از دسترسی مستقیم از کانتینر به میزبان با نشانی گیت‌وی پیش‌فرض است. مورد اخیر را می‌توان با انتقال \fB--map-gw\fP در گزینه‌های اختصاصی pasta بازنویسی کرد.
.br
برای یکپارچگی بهتر با مدیریت DNS، گزینه \fB--dns-forward 169.254.1.1\fP به طور پیش‌فرض منتقل می‌شود و این نشانی به عنوان اولین تحلیل‌گر به resolv.conf(5) اضافه می‌گردد. در صورت نیاز به IP دیگر، ارسال صریح \fB--dns-forward\fP ممکن است.
.br
برای کارکرد ورودی \fBhost.containers.internal\fR در /etc/hosts و اجازه اتصال به میزبان، \fB--map-guest-addr 169.254.1.2\fP به طور پیش‌فرض منتقل می‌شود.
.br
همچنین در صورتی که هیچ فورواردینگی برای درگاه‌های TCP یا UDP از میزبان به کانتینر تنظیم نشده باشد، گزینه‌های \fB-t none\fP و \fB-u none\fP منتقل می‌شوند تا فوروارد خودکار پورت بر اساس پورت‌های متصل غیرفعال شود. به همین ترتیب \fB-T none\fP و \fB-U none\fP برای غیرفعال کردن همین عملکرد از کانتینر به میزبان ارائه می‌شوند.
.br
تمام گزینه‌ها را می‌توان در \fBcontainers.conf(5)\fP نیز تنظیم کرد؛ کلید \fBpasta_options\fR را ذیل بخش network در آن فایل ببینید.
.br
چند مثال:
.RS
.IP \(bu 2
\fBpasta:--map-gw\fP: اجازه به کانتینر برای دسترسی مستقیم به میزبان با استفاده از نشانی گیت‌وی.
.IP \(bu 2
\fBpasta:--mtu,1500\fP: تعیین MTU به اندازه ۱۵۰۰ بایت برای رابط \fItap\fP در کانتینر.
.IP \(bu 2
\fBpasta:--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,-m,1500,--no-ndp,--no-dhcpv6,--no-dhcp\fP:
غیرفعال کردن IPv6، تخصیص \fB10.0.2.0/24\fR به رابط \fBtap0\fR در کانتینر با گیت‌وی \fB10.0.2.3\fR، فعال‌سازی فورواردر DNS در \fB10.0.2.3\fR، تنظیم MTU روی ۱۵۰۰ بایت، غیرفعال کردن پشتیبانی از NDP، DHCPv6 و DHCP.
.IP \(bu 2
\fBpasta:-I,tap0,--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,--no-ndp,--no-dhcpv6,--no-dhcp\fP:
مشابه بالا اما واگذاری مقدار MTU روی ۶۵۵۲۰ بایت.
.IP \(bu 2
\fBpasta:-t,auto,-u,auto,-T,auto,-U,auto\fP: فعال‌سازی فورواردینگ خودکار پورت بر اساس پورت‌های متصل مشاهده‌شده از هر دو سمت میزبان و کانتینر.
.IP \(bu 2
\fBpasta:-T,5201\fP: فعال‌سازی فورواردینگ پورت TCP به شماره ۵۲۰۱ از کانتینر به میزبان با استفاده از رابط loopback به‌جای رابط tap جهت افزایش کارایی.
.RE

.PP
در صورت استفاده از \fB--dns\fP، \fB--dns-option\fP یا \fB--dns-search\fP با \fB--network\fP تنظیم‌شده روی \fBnone\fP یا \fBcontainer:\fP\fIid\fP نامعتبر است.

.PP
اگر همراه با \fB--pod\fP استفاده شود، کانتینر به فضای نام شبکه پاد ملحق می‌شود.

.SS \fB--network-alias\fP=\fIalias\fP
افزودن نام مستعار در سطح شبکه برای کانتینر، با تنظیم نام مستعار برای تمامی شبکه‌هایی که کانتینر به آن‌ها می‌پیوندد. برای تعیین نام تنها برای یک شبکه خاص، از گزینه alias به شرح توضیح‌داده‌شده ذیل گزینه \fB--network\fP استفاده کنید.
اگر شبکه دارای DNS فعال باشد (\fBpodman network inspect -f {{.DNSEnabled}} <name>\fR)،
این نام‌های مستعار برای تحلیل نام روی شبکه داده‌شده قابل استفاده هستند. این گزینه می‌تواند چندین بار مشخص شود.

.SS \fB--no-healthcheck\fP
غیرفعال کردن هرگونه بررسی سلامت تعریف‌شده برای کانتینر.

.SS \fB--no-hostname\fP
ایجاد نکردن فایل \fI/etc/hostname\fP در کانتینرها.

.PP
به طور پیش‌فرض پادمن فایل \fI/etc/hostname\fP را مدیریت کرده و نام میزبان کانتینر را اضافه می‌کند. هنگامی که \fB--no-hostname\fP تنظیم شود، فایل \fI/etc/hostname\fP ایمیج بدون تغییر حفظ می‌شود.

.SS \fB--no-hosts\fP
عدم دستکاری فایل \fB/etc/hosts\fR درون کانتینر.

.PP
پادمن به صورت پیش‌فرض کنترل فایل \fB/etc/hosts\fR کانتینر را در دست گرفته و ورودی‌هایی برای نام کانتینر (گزینه \fB--name\fP)، نام میزبان (گزینه \fB--hostname\fP)، میزبان‌های داخلی \fBhost.containers.internal\fR و \fBhost.docker.internal\fR و هر نام میزبان ارائه‌شده با گزینه \fB--add-host\fP اضافه می‌کند. برای جزئیات به گزینه \fB--add-host\fP مراجعه کنید. دادن \fB--no-hosts\fP این قابلیت را غیرفعال می‌کند تا فایل \fB/etc/hosts\fR ایمیج دست‌نخورده باقی بماند. همین نتیجه را می‌توان به صورت سراسری با تنظیم \fIno_hosts=true\fP در \fBcontainers.conf\fR به دست آورد.

.PP
این گزینه با \fB--add-host\fP تداخل دارد.

.SS \fB--oom-kill-disable\fP
غیرفعال کردن یا نکردن OOM Killer برای کانتینر.

.PP
این پرچم در سیستم‌های با cgroups V2 پشتیبانی نمی‌شود.

.SS \fB--oom-score-adj\fP=\fInum\fP
تنظیم ترجیحات OOM سیستم میزبان برای کانتینرها (مقادیر بین \fB-1000\fP تا \fB1000\fP را می‌پذیرد).

.PP
هنگام اجرا در حالت بدون ریشه، مقدار مشخص‌شده نمی‌تواند کمتر از oom_score_adj فرایند فعلی باشد. در این حالت، oom-score-adj به مقدار فرایند فعلی محدود می‌شود.

.SS \fB--os\fP=\fIOS\fP
بازنویسی سیستم‌عامل ایمیج مورد نظر برای دریافت (پیش‌فرض سیستم‌عامل میزبان است). برای مثال، \fBwindows\fR\&.
مگر اینکه بازنویسی شود، جستجوهای بعدی همان ایمیج در حافظه محلی با این سیستم‌عامل مطابقت خواهند داشت، صرف‌نظر از میزبان.

.SS \fB--passwd\fP
اجازه دادن به پادمن برای افزودن ورودی‌ها به etc/passwd/ و etc/group/ در صورت استفاده همراه با گزینه --user.
این گزینه برای بازنویسی تنظیمات کاربر ارائه‌شده توسط پادمن به نفع پیکربندی‌های نقطه ورود مانند libnss-extrausers به کار می‌رود.

.SS \fB--passwd-entry\fP=\fIENTRY\fP
سفارشی‌سازی ورودی نوشته‌شده در فایل \fB/etc/passwd\fR درون کانتینر هنگام استفاده از \fB--passwd\fR.

.PP
متغیرهای $USERNAME، $UID، $GID، $NAME و $HOME در زمان اجرا به طور خودکار با مقدار خود جایگزین می‌شوند.

.SS \fB--personality\fP=\fIpersona\fP
تعیین دامنه اجرا از طریق تابع personality(2) لینوکس.

.SS \fB--pid\fP=\fImode\fP
تنظیم حالت فضای نام PID برای کانتینر.
پیش‌فرض ایجاد یک فضای نام PID خصوصی برای کانتینر است.
.IP \(bu 2
\fBcontainer:\fP\fIid\fP: پیوستن به فضای نام PID کانتینر دیگر؛
.IP \(bu 2
\fBhost\fP: استفاده از فضای نام PID میزبان برای کانتینر. توجه داشته باشید که حالت host دسترسی کامل به PIDهای محلی را به کانتینر می‌دهد و ناامن تلقی می‌شود؛
.IP \(bu 2
\fBns:\fP\fIpath\fP: پیوستن به فضای نام PID مشخص‌شده؛
.IP \(bu 2
\fBprivate\fP: ایجاد یک فضای نام جدید برای کانتینر (پیش‌فرض).

.SS \fB--pidfile\fP=\fIpath\fP
هنگامی که مکان pidfile مشخص شود، PID فرایند کانتینر در فایل نوشته می‌شود. (این گزینه در کلاینت ریموت پادمن، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) در دسترس نیست).
اگر گزینه pidfile مشخص نشود، PID فرایند کانتینر در مسیر /run/containers/storage/${storage-driver}-containers/$CID/userdata/pidfile نوشته می‌شود.

.PP
پس از شروع کانتینر، مکان pidfile را می‌توان با دستور \fBpodman inspect\fR مشاهده کرد:

.EX
$ podman inspect --format '{{ .PidFile }}' $CID
/run/containers/storage/${storage-driver}-containers/$CID/userdata/pidfile
.EE

.SS \fB--pids-limit\fP=\fIlimit\fP
تنظیم محدودیت تعداد فرایندها (pids) کانتینر. برای داشتن تعداد نامحدود فرایند برای کانتینر، آن را روی \fB-1\fP تنظیم کنید. مقدار پیش‌فرض روی سیستم‌هایی که از کنترل‌کننده cgroup موسوم به "pids" پشتیبانی می‌کنند \fB2048\fP است.

.SS \fB--platform\fP=\fIOS/ARCH\fP
مشخص کردن پلتفرم برای انتخاب ایمیج (با arch-- و os-- تداخل دارد).
گزینه \fB--platform\fR می‌تواند برای بازنویسی معماری و سیستم‌عامل فعلی استفاده شود.
مگر اینکه بازنویسی شود، جستجوهای بعدی همان ایمیج در حافظه محلی با این پلتفرم مطابقت خواهند داشت، صرف‌نظر از میزبان.

.SS \fB--pod\fP=\fIname\fP
اجرای کانتینر در یک پاد موجود. اگر نام پاد دارای پیشوند \fBnew:\fP باشد، پادمن به صورت خودکار پاد را ایجاد می‌کند.
برای ایجاد یک پاد با گزینه‌های دقیق‌تر، پیش از ایجاد کانتینر از دستور \fBpodman pod create\fP استفاده کنید.
هنگامی که کانتینر با پادی شامل infra-container اجرا شود، ابتدا infra-container راه‌اندازی می‌شود.

.SS \fB--pod-id-file\fP=\fIfile\fP
اجرای کانتینر در یک پاد موجود و خواندن شناسه پاد از \fIfile\fP مشخص‌شده.
هنگامی که کانتینر درون پادی دارای یک infra-container اجرا شود، ابتدا infra-container شروع می‌شود.

.SS \fB--preserve-fd\fP=\fIFD1[,FD2,...]\fP
انتقال توصیف‌کننده‌های فایل اضافی مشخص‌شده در لیست جداشده با کاما به فرایند. می‌تواند چندین بار مشخص شود.
این گزینه تنها با زمان اجرای OCI موسوم به crun پشتیبانی می‌شود. استفاده از این گزینه با سایر زمان‌های اجرای OCI ممکن است مخاطره امنیتی داشته باشد.

.PP
(این گزینه در کلاینت ریموت پادمن، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) در دسترس نیست)

.SS \fB--preserve-fds\fP=\fIN\fP
انتقال N توصیف‌کننده فایل اضافی به فرایند (علاوه بر 0، 1 و 2).
تعداد کل توصیف‌کننده‌های فایل 3+N است.
(این گزینه در کلاینت ریموت پادمن، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2) در دسترس نیست)

.SS \fB--privileged\fP
اعطای امتیازات گسترده به این کانتینر. مقدار پیش‌فرض \fBfalse\fP است.

.PP
به طور پیش‌فرض کانتینرهای پادمن فاقد امتیاز هستند (\fB=false\fP) و برای نمونه نمی‌توانند بخش‌هایی از سیستم‌عامل را دستکاری کنند. این به این دلیل است که کانتینر به صورت پیش‌فرض تنها دسترسی محدودی به دستگاه‌ها دارد. به یک کانتینر "با امتیاز" همان دسترسی به دستگاه‌ها داده می‌شود که کاربر راه‌انداز کانتینر دارد، به استثنای کنسول‌های مجازی (\fI/dev/tty\\d+\fP) هنگام اجرا در حالت systemd (\fB--systemd=always\fP).

.PP
یک کانتینر با امتیاز ویژگی‌های امنیتی که کانتینر را از میزبان ایزوله می‌کنند خاموش می‌کند. قابلیت‌های حذف‌شده، دستگاه‌های محدود، نقاط مانت فقط‌خواندنی، جداسازی Apparmor/SELinux و فیلترهای Seccomp همگی غیرفعال می‌شوند. به دلیل ویژگی‌های امنیتی غیرفعال‌شده، فیلد privileged تقریباً هرگز نباید تنظیم شود زیرا کانتینرها می‌توانند به راحتی از حصار ایزولاسیون خارج شوند.

.PP
کانتینرهایی که در فضای نام کاربری (مانند کانتینرهای بدون ریشه یا rootless) اجرا می‌شوند نمی‌توانند امتیازاتی فراتر از کاربری که آن‌ها را اجرا کرده است داشته باشند.

.SS \fB--publish\fP, \fB-p\fP=\fI[[hostIP:][hostPort]:]containerPort[/protocol]\fP
انتشار یک درگاه (پورت) یا بازه‌ای از درگاه‌های کانتینر روی میزبان.

.PP
هر دو مقدار \fIhostPort\fP و \fIcontainerPort\fP می‌توانند به صورت بازه‌ای از درگاه‌ها مشخص شوند. هنگام مشخص کردن بازه برای هر دو، تعداد درگاه‌های کانتینر در بازه باید با تعداد درگاه‌های میزبان در بازه مطابقت داشته باشد.

.PP
اگر \fIhostIP\fP برابر با \fB0.0.0.0\fR باشد، تنها به آدرس‌های IPv4 متصل می‌شود؛ اگر روی \fB[::]\fR تنظیم شود تنها به آدرس‌های IPv6 متصل می‌شود. در تمامی موارد دیگر، دقیقاً به همان آدرس IP داده‌شده متصل خواهد شد. اگر \fIhostIP\fP اصلاً تنظیم نشود، درگاه روی تمام آدرس‌های IP میزبان، هم v4 و هم v6 (در صورت امکان) متصل می‌شود.

.PP
مقدار پیش‌فرض \fIhostIP\fP را می‌توان در \fBcontainers.conf(5)\fP با استفاده از گزینه \fBdefault_host_ips\fR در بخش \fB[network]\fR پیکربندی کرد. این گزینه آرایه‌ای را برای تنظیم چندین آدرس IP اتصال می‌پذیرد. برای نمونه تنظیم \fBdefault_host_ips = ["127.0.0.1", "::1"]\fR باعث می‌شود درگاه به ترتیب روی آدرس محلی ipv4 و ipv6 منتشر شود. تعیین صریح \fIhostIP\fP در خط فرمان همواره تنظیمات پیکربندی را لغو می‌کند.

.PP
به طور پیش‌فرض، پادمن درگاه‌های TCP را منتشر می‌کند. برای انتشار درگاه UDP، پروتکل \fBudp\fR را مشخص کنید. برای انتشار هر دو درگاه TCP و UDP، گزینه \fB--publish\fR را دو بار با پروتکل‌های \fBtcp\fR و \fBudp\fR مشخص کنید. کانتینرهای با ریشه (Rootful) همچنین می‌توانند درگاه‌ها را با پروتکل \fBsctp\fR منتشر کنند.

.PP
نیازی به مشخص کردن درگاه میزبان نیست (برای نمونه \fBpodman run -p 127.0.0.1::80\fR). اگر مشخص نشود، یک درگاه تصادفی روی میزبان به درگاه کانتینر اختصاص می‌یابد.

.PP
برای مشاهده نگاشت واقعی از \fBpodman port\fP استفاده کنید: \fBpodman port $CONTAINER $CONTAINERPORT\fR\&.

.PP
انتشار درگاه تنها برای کانتینرهایی پشتیبانی می‌شود که از فضای نام شبکه اختصاصی خود از طریق شبکه‌های \fBbridge\fR یا حالت شبکه \fBpasta\fR استفاده می‌کنند.

.PP
برای شبکه‌های bridge بدون ریشه، فورواردینگ درگاه به طور پیش‌فرض از \fBrootlessport\fR استفاده می‌کند که یک پروکسی فضای کاربری است و IP مبدا کلاینت را حفظ نمی‌کند. تنظیم \fBrootless_port_forwarder="pasta"\fR در بخش \fB[network]\fR در \fBcontainers.conf(5)\fP فورواردینگ را به سطح هسته pasta از طریق \fBpesto\fR تغییر می‌دهد و آدرس IP اصلی کلاینت را درون کانتینر حفظ می‌کند. این گزینه آزمایشی است و رفتار آن ممکن است تغییر کند.

.PP
\fBنکته:\fP اگر کانتینر درون یک پاد اجرا شود، نیازی به انتشار درگاه برای کانتینرهای داخل پاد نیست. درگاه تنها باید توسط خود پاد منتشر شود. پشته‌های شبکه پاد مانند پشته شبکه روی میزبان عمل می‌کنند — به این معنی که انواع کانتینرها در پاد و برنامه‌های درون کانتینر همگی در یک رابط شبکه، آدرس IP و درگاه‌های مرتبط مشترک هستند. اگر یک کانتینر به درگاهی متصل شود، هیچ کانتینر دیگری در داخل پاد نمی‌تواند در زمان استفاده از آن درگاه استفاده کند. کانتینرهای درون پاد همچنین می‌توانند از طریق localhost ارتباط برقرار کنند، به این صورت که یک کانتینر به localhost در پاد متصل شود و دیگری به آن درگاه متصل گردد.

.SS \fB--publish-all\fP, \fB-P\fP
انتشار تمام درگاه‌های اکسپوزشده روی درگاه‌های تصادفی رابط‌های شبکه میزبان. پیش‌فرض \fBfalse\fP است.

.PP
هنگامی که روی \fBtrue\fP تنظیم شود، تمام درگاه‌های اکسپوزشده را روی رابط‌های میزبان منتشر می‌کند. اگر کاربر از \fB-P\fP (یا \fB-p\fP) استفاده کند، پادمن درگاه اکسپوزشده را روی میزبان در دسترس قرار داده و درگاه‌ها برای هر کلاینتی که به میزبان دسترسی داشته باشد قابل دسترسی خواهند بود.

.PP
هنگام استفاده از این گزینه، پادمن هر درگاه اکسپوزشده را به یک درگاه تصادفی روی میزبان درون یک بازه درگاه موقت (ephemeral) تعریف‌شده توسط \fI/proc/sys/net/ipv4/ip_local_port_range\fP متصل می‌کند. برای یافتن نگاشت میان درگاه‌های میزبان و درگاه‌های اکسپوزشده، از \fBpodman port\fP استفاده کنید.

.SS \fB--pull\fP=\fIpolicy\fP
سیاست واکشی (Pull) ایمیج. پیش‌فرض \fBmissing\fP است.
.IP \(bu 2
\fBalways\fP: همواره ایمیج را واکشی کن و در صورت شکست خطایی ایجاد کن.
.IP \(bu 2
\fBmissing\fP: ایمیج را تنها زمانی واکشی کن که در فضای ذخیره‌سازی محلی کانتینرها موجود نباشد. اگر ایمیجی یافت نشد و واکشی شکست خورد خطا بده.
.IP \(bu 2
\fBnever\fP: هرگز ایمیج را واکشی نکن بلکه از ایمیج موجود در فضای ذخیره‌سازی محلی استفاده کن. اگر ایمیجی پیدا نشد خطا بده.
.IP \(bu 2
\fBnewer\fP: در صورتی که ایمیج روی رجیستری جدیدتر از ایمیج موجود در ذخیره‌ساز محلی کانتینرها باشد واکشی کن. ایمیج در صورتی جدیدتر تلقی می‌شود که دایجست‌های آن‌ها متفاوت باشد. مقایسه مهرهای زمانی مستعد خطاست. اگر ایمیج محلی یافت شد خطاهای واکشی نادیده گرفته می‌شوند.

.SS \fB--quiet\fP, \fB-q\fP
پنهان‌سازی خروجی اطلاعات هنگام واکشی ایمیج‌ها.

.SS \fB--rdt-class\fP=\fIintel-rdt-class-of-service\fP
کلاس سرویس (CLOS یا COS) را برای اجرای کانتینر تنظیم می‌کند. بر اساس قابلیت فناوری تخصیص حافظه کش (CAT) که بخشی از مجموعه قابلیت‌های فناوری مدیر منبع اینتل (RDT) است، تمام فرایندهای کانتینر درون COS از پیش پیکربندی‌شده اجرا می‌شوند که بخشی از حافظه کش را نشان می‌دهد. COS باید با استفاده از یک فایل‌سیستم شبه‌واقعی (که معمولاً در \fB/sys/fs/resctrl\fR سوار می‌شود) که توسط درایور هسته resctrl فراهم می‌گردد ایجاد و پیکربندی شود. انتساب کانتینر به یک COS نیازمند امتیازات ریشه است و بنابراین در محیط‌های بدون ریشه کار نمی‌کند. در حال حاضر این قابلیت تنها با زمان اجرای \fBrunc\fR پشتیبانی می‌شود. برای اطلاعات بیشتر در خصوص ایجاد یک COS پیش از اختصاص کانتینر به آن، به
\[la]https://docs.kernel.org/arch/x86/resctrl.html\[ra] مراجعه کنید.

.SS \fB--read-only\fP
سوار کردن سیستم‌فایل ریشه کانتینر به صورت فقط‌خواندنی.

.PP
به طور پیش‌فرض، سیستم‌فایل‌های ریشه کانتینر قابل نوشتن هستند و به فرایندها اجازه می‌دهند در هر نقطه‌ای فایل بنویسند. با مشخص کردن فلگ \fB--read-only\fP، سیستم‌فایل ریشه کانتینر به صورت فقط‌خواندنی سوار شده و هرگونه نوشتن ممنوع می‌شود.

.SS \fB--read-only-tmpfs\fP
هنگام اجرای کانتینرهای با گزینه --read-only، یک tmpfs خواندنی-نوشتنی روی \fI/dev\fP، \fI/dev/shm\fP، \fI/run\fP، \fI/tmp\fP و \fI/var/tmp\fP سوار کن. پیش‌فرض \fBtrue\fP است.

.TS
allbox;
l l l l 
l l l l .
\fB--read-only\fP	\fB--read-only-tmpfs\fP	\fB/\fP	\fB/run, /tmp, /var/tmp\fP
true	true	r/o	r/w
true	false	r/o	r/o
false	false	r/w	r/w
false	true	r/w	r/w
.TE

.PP
هنگامی که \fB--read-only=true\fP و \fB--read-only-tmpfs=true\fP باشد، tmpfsهای اضافی روی دایرکتوری‌های /tmp، /run و /var/tmp سوار می‌شوند.

.PP
هنگامی که \fB--read-only=true\fP و \fB--read-only-tmpfs=false\fP باشد، مسیرهای /dev و /dev/shm به صورت فقط‌خواندنی علامت‌گذاری شده و هیچ tmpfsای روی /tmp، /run و /var/tmp سوار نمی‌شود. این دایرکتوری‌ها از ایمیج زیرین نمایان می‌شوند، به این معنی که به طور پیش‌فرض فقط‌خواندنی هستند. این کار کانتینر را کاملاً فقط‌خواندنی می‌کند. هیچ دایرکتوری قابل‌نوشتنی در کانتینر وجود نخواهد داشت. در این حالت دایرکتوری‌های قابل نوشتن باید از طریق حجم‌ها (volumes) یا مانت‌های خارجی افزوده شوند.

.PP
به طور پیش‌فرض، هنگامی که \fB--read-only=false\fP باشد، دایرکتوری‌های /dev و /dev/shm خواندنی/نوشتنی هستند، و /tmp، /run و /var/tmp دایرکتوری‌های خواندنی/نوشتنی از ایمیج کانتینر می‌باشند.

.SS \fB--replace\fP
اگر کانتینر دیگری با همین نام از قبل وجود داشته باشد، آن را جایگزین و حذف کن. پیش‌فرض \fBfalse\fP است.

.SS \fB--requires\fP=\fIcontainer\fP
مشخص کردن یک یا چند وابستگی. یک وابستگی کانتینری وابسته است که پیش از شروع این کانتینر اجرا می‌شود. کانتینرها را می‌توان با نام یا شناسه مشخص کرد و چند کانتینر با کاما از هم جدا می‌شوند.

.SS \fB--restart\fP=\fIpolicy\fP
سیاست راه‌اندازی مجدد برای اعمال پس از خروج کانتینرها. اگر کانتینر از طریق دستورات \fBpodman kill\fP یا \fBpodman stop\fP متوقف شده باشد، سیاست راه‌اندازی مجدد اثری نخواهد داشت.

.PP
مقادیر مجاز برای \fIpolicy\fP عبارتند از:
.IP \(bu 2
\fBno\fR                       : کانتینرها پس از خروج دوباره راه‌اندازی نشوند
.IP \(bu 2
\fBnever\fR                    : مترادف برای \fBno\fP؛ کانتینرها پس از خروج دوباره راه‌اندازی نشوند
.IP \(bu 2
\fBon-failure[:max_retries]\fR : راه‌اندازی مجدد کانتینرها در صورتی که با کد خروج غیرصفر خارج شوند؛ تلاش مجدد نامحدود است یا تا رسیدن به سقف اختیاری \fImax_retries\fP تکرار می‌شود
.IP \(bu 2
\fBalways\fR                   : راه‌اندازی مجدد کانتینرها هنگام خروج بدون توجه به وضعیت آن، با تلاش مجدد نامحدود
.IP \(bu 2
\fBunless-stopped\fR           : راه‌اندازی مجدد کانتینرها هنگام خروج، مگر اینکه کانتینر صریحاً توسط کاربر متوقف شده باشد. پس از راه‌اندازی مجدد سیستم، کانتینرهای دارای این سیاست توسط podman-restart.service تنها در صورتی دوباره راه‌اندازی می‌شوند که پیش از ریبوت سیستم صریحاً توسط کاربر متوقف نشده باشند. این با \fBalways\fP تفاوت دارد که کانتینرها را پس از ریبوت سیستم بدون توجه به اینکه توسط کاربر متوقف شده بودند یا خیر، راه‌اندازی می‌کند

.PP
پادمن یک فایل واحد systemd به نام podman-restart.service ارائه می‌دهد که کانتینرها را پس از ریبوت سیستم دوباره راه‌اندازی می‌کند.

.PP
هنگام اجرای کانتینرها در سرویس‌های systemd، از قابلیت restart ارائه‌شده توسط خود systemd استفاده کنید. به عبارت دیگر، از این گزینه در واحدهای کانتینری استفاده نکنید؛ در عوض دستور \fBRestart=\fR را در بخش \fB[Service]\fR تنظیم نمایید. به \fBpodman-systemd.unit\fP(5) و \fBsystemd.service\fP(5) مراجعه کنید.

.SS \fB--retry\fP=\fIattempts\fP
تعداد دفعات تلاش مجدد برای واکشی یا ارسال ایمیج‌ها بین رجیستری و حافظه محلی در صورت بروز خطا. پیش‌فرض \fB3\fP است.

.SS \fB--retry-delay\fP=\fIduration\fP
مدت‌زمان تاخیر بین تلاش‌های مجدد هنگام واکشی یا ارسال ایمیج‌ها میان رجیستری و حافظه محلی در صورت بروز خطا. مقدار پیش‌فرض با دو ثانیه شروع شده و سپس به صورت نمایی افزایش می‌یابد. اگر این مقدار تنظیم شود، تاخیر مشخص‌شده استفاده شده و عقب‌نشینی نمایی رخ نمی‌دهد.

.SS \fB--rm\fP
حذف خودکار کانتینر و هرگونه حجم ناشناس (unnamed) مرتبط با کانتینر پس از خروج آن. پیش‌فرض \fBfalse\fP است.

.SS \fB--rmi\fP
پس از خروج کانتینر، ایمیج آن را حذف کن مگر اینکه کانتینر دیگری در حال استفاده از آن باشد. این گزینه متضمن \fB--rm\fP روی کانتینر جدید است. پیش‌فرض \fBfalse\fP است.

.SS \fB--rootfs\fP
در صورت مشخص شدن، نخستین آرگومان به یک کانتینر استخراج‌شده روی سیستم‌فایل اشاره دارد.

.PP
این گزینه برای اجرای کانتینر بدون نیاز به مدیریت ایمیج مفید است؛ فرض می‌شود ریشه سیستم‌فایل (rootfs) کانتینر به صورت خارجی مدیریت می‌شود.

.PP
\fBمانت‌های Overlay Rootfs\fR

.PP
فلگ \fB:O\fR به پادمن می‌گوید دایرکتوری حاصل از مسیر rootfs را به عنوان فضای ذخیره‌سازی با استفاده از \fBسیستم‌فایل overlay\fR سوار کند. فرایندهای کانتینر می‌توانند محتوای درون نقطه مانت را تغییر دهند که در فضای ذخیره‌سازی کانتینر در یک دایرکتوری جداگانه ذخیره می‌شود. در اصطلاحات overlay، دایرکتوری مبدا lower است و دایرکتوری ذخیره‌سازی کانتینر upper می‌باشد. تغییرات اعمال‌شده در نقطه مانت پس از اتمام اجرای کانتینر از بین می‌روند، مشابه حالتی که یک نقطه مانت tmpfs از حالت مانت خارج شود.

.PP
نکته: در سیستم‌های دارای \fBSELinux\fP، سیستم‌فایل ریشه به برچسب صحیح نیاز دارد که به طور پیش‌فرض \fBunconfined_u:object_r:container_file_t:s0\fP است.

.PP
\fBidmap\fR

.PP
اگر \fBidmap\fR مشخص شود، یک مانت با نگاشت شناسه (idmapped mount) به فضای نام کاربری هدف در کانتینر ایجاد می‌کند. گزینه idmap از نگاشت سفارشی پشتیبانی می‌کند که می‌تواند با فضای نام کاربری مورد استفاده کانتینر متفاوت باشد. نگاشت را می‌توان پس از گزینه idmap به این صورت مشخص کرد: \fBidmap=uids=0-1-10#10-11-10;gids=0-100-10\fR\&. برای هر سه‌تایی، مقدار اول شروع شناسه‌های سیستم‌فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم ارائه می‌شود. بازه‌های متعدد با علامت # از یکدیگر جدا می‌شوند.

.SS \fB--sdnotify\fP=\fBcontainer\fP | \fIconmon\fP | \fIhealthy\fP | \fIignore\fP
نحوه استفاده از NOTIFY_SOCKET که توسط systemd و با Type=notify ارسال می‌شود را مشخص می‌کند.

.PP
مقدار پیش‌فرض \fBcontainer\fP است، به این معنی که به زمان اجرای OCI اجازه می‌دهد سوکت را به کانتینر پروکسی کند تا اعلان‌های آمادگی را دریافت نماید. پادمن مقدار MAINPID را روی pid فرایند conmon تنظیم می‌کند.
گزینه \fBconmon\fP مقدار MAINPID را روی pid فرایند conmon تنظیم کرده و پس از راه‌اندازی کانتینر پیام READY را ارسال می‌کند. سوکت هرگز به زمان اجرا یا کانتینر منتقل نمی‌شود.
گزینه \fBhealthy\fP مقدار MAINPID را روی pid فرایند conmon تنظیم کرده و زمانی که کانتینر سالم شد پیام READY را می‌فرستد؛ نیازمند تنظیم یک بررسی سلامت (healthcheck) است. سوکت هرگز به زمان اجرا یا کانتینر منتقل نمی‌شود.
گزینه \fBignore\fP متغیر NOTIFY_SOCKET را از محیط برای خود و فرایندهای فرزند حذف می‌کند، برای شرایطی که فرایندی بالاتر از پادمن از NOTIFY_SOCKET استفاده کرده و پادمن از آن استفاده نمی‌کند.

.SS \fB--seccomp-policy\fP=\fIpolicy\fP
سیاست انتخاب نمایه seccomp را مشخص می‌کند. اگر روی \fIimage\fP تنظیم شود، پادمن به دنبال برچسب "io.containers.seccomp.profile" در پیکربندی ایمیج کانتینر می‌گردد و از مقدار آن به عنوان نمایه seccomp استفاده می‌کند. در غیر این صورت، پادمن از سیاست \fIdefault\fP پیروی کرده و نمایه پیش‌فرض را اعمال می‌کند، مگر اینکه از طریق \fI--security-opt seccomp\fP مطابق توضیحات زیر جور دیگری مشخص شده باشد.

.PP
توجه داشته باشید که این ویژگی آزمایشی است و ممکن است در آینده تغییر کند.

.SS \fB--secret\fP=\fIsecret[,opt=opt ...]\fP
اعطای دسترسی کانتینر به یک سکرت (داده محرمانه). می‌تواند چندین بار مشخص شود.

.PP
یک سکرت بلوکی از داده‌های حساس است که کانتینر در زمان اجرا به آن نیاز دارد اما در ایمیج یا کنترل نسخه ذخیره نمی‌شود، مانند نام‌های کاربری و گذرواژه‌ها، گواهی‌ها و کلیدهای TLS، کلیدهای SSH یا سایر رشته‌های مهم عمومی یا محتوای باینری (تا حداکثر حجم ۵۱۲ کیلوبایت).

.PP
هنگامی که سکرت‌ها با نوع \fBmount\fR مشخص می‌شوند، در زمان ایجاد کانتینر کپی شده و درون کانتینر سوار می‌شوند. هنگامی که با نوع \fBenv\fR مشخص شوند، سکرت به عنوان یک متغیر محیطی درون کانتینر تنظیم می‌شود. سکرت‌ها در زمان ایجاد کانتینر درون آن نوشته می‌شوند و ویرایش سکرت با دستورات \fBpodman secret\fR پس از ایجاد کانتینر، بر سکرت درون کانتینر اثر می‌گذارد.

.PP
سکرت‌ها و محل ذخیره‌سازی آن‌ها با دستور \fBpodman secret\fR مدیریت می‌شوند.

.PP
گزینه‌های سکرت
.IP \(bu 2
\fBtype=mount|env\fR    : نحوه ارائه سکرت به کانتینر.
                    مقدار \fBmount\fR سکرت را به عنوان فایل درون کانتینر سوار می‌کند.
                    مقدار \fBenv\fR سکرت را به عنوان یک متغیر محیطی ارائه می‌دهد.
                    پیش‌فرض \fBmount\fR است.
.IP \(bu 2
\fBtarget=target\fR     : مقصد سکرت.
                    برای سکرت‌های مانت‌شده، این مسیر فایل سکرت در داخل کانتینر است.
                    اگر یک مسیر مطلق و کامل ارائه شود، سکرت در همان مکان سوار می‌شود.
                    در غیر این صورت، سکرت به صورت پیش‌فرض در \fB/run/secrets/target\fR برای کانتینرهای لینوکس یا
                    \fB/var/run/secrets/target\fR برای کانتینرهای FreeBSD سوار می‌شود.
                    اگر مقصد تنظیم نشود، سکرت به طور پیش‌فرض در \fB/run/secrets/secretname\fR سوار می‌گردد.
                    برای سکرت‌های محیطی (env)، این کلید متغیر محیطی است. پیش‌فرض \fBsecretname\fR است.
.IP \(bu 2
\fBuid=0\fR             : شناسه کاربر (UID) سکرت. پیش‌فرض 0 است. فقط برای سکرت نوع mount.
.IP \(bu 2
\fBgid=0\fR             : شناسه گروه (GID) سکرت. پیش‌فرض 0 است. فقط برای سکرت نوع mount.
.IP \(bu 2
\fBmode=0\fR            : حالت دسترسی (Mode) سکرت. پیش‌فرض 0444 است. فقط برای سکرت نوع mount.

.PP
مثال‌ها

.PP
سوار کردن در \fB/my/location/mysecret\fR با UID برابر با 1:

.EX
--secret mysecret,target=/my/location/mysecret,uid=1
.EE

.PP
سوار کردن در \fB/run/secrets/customtarget\fR با دسترسی 0777:

.EX
--secret mysecret,target=customtarget,mode=0777
.EE

.PP
ایجاد یک متغیر محیطی سکرت به نام \fBENVSEC\fR:

.EX
--secret mysecret,type=env,target=ENVSEC
.EE

.SS \fB--security-opt\fP=\fIoption\fP
گزینه‌های امنیتی
.IP \(bu 2
\fBapparmor=unconfined\fP : غیرفعال کردن محدودسازی apparmor برای کانتینر
.IP \(bu 2
\fBapparmor\fP=\fIalternate-profile\fP : تنظیم نمایه محدودسازی apparmor برای کانتینر
.IP \(bu 2
\fBlabel=user:\fP\fIUSER\fP: تنظیم برچسب کاربر برای فرایندهای کانتینر
.IP \(bu 2
\fBlabel=role:\fP\fIROLE\fP: تنظیم برچسب نقش برای فرایندهای کانتینر
.IP \(bu 2
\fBlabel=type:\fP\fITYPE\fP: تنظیم برچسب نوع فرایند برای فرایندهای کانتینر
.IP \(bu 2
\fBlabel=level:\fP\fILEVEL\fP: تنظیم برچسب سطح برای فرایندهای کانتینر
.IP \(bu 2
\fBlabel=filetype:\fP\fITYPE\fP: تنظیم برچسب نوع فایل برای فایل‌های کانتینر
.IP \(bu 2
\fBlabel=disable\fP: غیرفعال کردن جداسازی برچسب‌ها برای کانتینر

.PP
نکته: برچسب‌گذاری را می‌توان برای تمام کانتینرها با تنظیم label=false در فایل \fBcontainers.conf\fP (\fB/etc/containers/containers.conf\fR یا \fB$HOME/.config/containers/containers.conf\fR) غیرفعال کرد.
.IP \(bu 2
\fBlabel=nested\fP: اجازه اعمال تغییرات SELinux را درون کانتینر می‌دهد. تا زمانی که سیاست SELinux اجازه دهد، کانتینرها مجاز به اصلاح برچسب‌های SELinux روی فایل‌ها و فرایندها هستند. بدون \fBnested\fP، کانتینرها SELinux را حتی در صورت فعال بودن روی میزبان غیرفعال می‌بینند و از تنظیم هرگونه برچسب منع می‌شوند.
.IP \(bu 2
\fBmask\fP=\fI/path/1:/path/2\fP: مسیرهای ماسک‌شده که با دونقطه از هم جدا شده‌اند. دسترسی به یک مسیر ماسک‌شده درون کانتینر امکان‌پذیر نیست.
.IP \(bu 2
\fBno-new-privileges\fP: جلوگیری از کسب امتیازات اضافی توسط فرایندهای کانتینر از طریق فراخوانی سیستمی \fBexecve(2)\fR (برای نمونه از طریق بیت‌های setuid یا setgid، یا از طریق قابلیت‌های فایل). برنامه‌هایی که برای تغییر شناسه کاربری یا گروه به بیت‌های setuid/setgid متکی هستند دیگر قادر به انجام آن نخواهند بود و هرگونه قابلیت فایلی که به فایل اجرایی اضافه شود (مثلاً از طریق \fBsetcap\fR) به مجموعه قابلیت‌های مجاز افزوده نخواهد شد. برای جزئیات بیشتر به: https://docs.kernel.org/userspace-api/no_new_privs.html مراجعه کنید.
.IP \(bu 2
\fBseccomp=unconfined\fP: غیرفعال کردن محدودسازی seccomp برای کانتینر.
.IP \(bu 2
\fBseccomp=profile.json\fP: فایل JSON مورد استفاده به عنوان فیلتر seccomp. توجه داشته باشید که انوتیشن \fBio.podman.annotations.seccomp\fR با مقدار مشخص‌شده تنظیم می‌شود همان‌طور که در \fBpodman inspect\fR مشاهده می‌شود.
.IP \(bu 2
\fBproc-opts\fP=\fIOPTIONS\fP : لیستی از گزینه‌های جداشده با کاما برای استفاده در مانت /proc. جزئیات بیشتر برای گزینه‌های ممکن مانت در صفحه راهنمای \fBproc(5)\fP آمده است.
.IP \(bu 2
\fBunmask\fP=\fIALL\fP یا \fI/path/1:/path/2\fP، یا مسیرهای بسط‌یافته شل (/proc/*): مسیرهایی برای لغو ماسک که با دونقطه جدا می‌شوند. اگر روی \fBALL\fP تنظیم شود، ماسک تمام مسیرهایی که به طور پیش‌فرض ماسک یا فقط‌خواندنی شده‌اند لغو می‌شود. مسیرهای ماسک‌شده پیش‌فرض عبارتند از \fB/proc/acpi, /proc/kcore, /proc/keys, /proc/latency_stats, /proc/sched_debug, /proc/scsi, /proc/timer_list, /proc/timer_stats, /sys/firmware, and /sys/fs/selinux\fP, \fB/sys/devices/virtual/powercap\fP\&. مسیرهای پیش‌فرضی که فقط‌خواندنی هستند عبارتند از \fB/proc/asound\fP, \fB/proc/bus\fP, \fB/proc/fs\fP, \fB/proc/irq\fP, \fB/proc/sys\fP, \fB/proc/sysrq-trigger\fP, \fB/sys/fs/cgroup\fP\&.

.PP
نکته: برچسب‌گذاری را می‌توان برای تمام کانتینرها با تنظیم \fBlabel=false\fP در فایل \fBcontainers.conf\fP(5) غیرفعال کرد.

.SS \fB--shm-size\fP=\fInumber[unit]\fP
اندازه \fI/dev/shm\fP\&. یک \fIunit\fP می‌تواند \fBb\fP (بایت)، \fBk\fP (کیبی‌بایت)، \fBm\fP (مبی‌بایت)، یا \fBg\fP (گیبی‌بایت) باشد. اگر واحد حذف شود، سیستم از بایت استفاده می‌کند. اگر اندازه مشخص نشود، پیش‌فرض \fB64m\fP است. هنگامی که \fIsize\fP برابر با \fB0\fP باشد، هیچ محدودیتی روی حافظه استفاده‌شده برای IPC توسط کانتینر وجود ندارد. این گزینه با \fB--ipc=host\fP تداخل دارد.

.SS \fB--shm-size-systemd\fP=\fInumber[unit]\fP
اندازه مانت‌های tmpfs اختصاصی systemd مانند /run، /run/lock، /var/log/journal و /tmp. یک \fIunit\fP می‌تواند \fBb\fP (بایت)، \fBk\fP (کیبی‌بایت)، \fBm\fP (مبی‌بایت)، یا \fBg\fP (گیبی‌بایت) باشد. اگر واحد حذف شود، سیستم از بایت استفاده می‌کند. اگر اندازه حذف شود، پیش‌فرض \fB64m\fP است. هنگامی که \fIsize\fP برابر با \fB0\fP باشد، میزان استفاده به ۵۰٪ حافظه در دسترس میزبان محدود می‌شود.

.SS \fB--sig-proxy\fP
پروکسی کردن سیگنال‌های دریافتی به فرایند کانتینر. سیگنال‌های SIGCHLD، SIGURG، SIGSTOP و SIGKILL پروکسی نمی‌شوند.

.PP
پیش‌فرض \fBtrue\fP است.

.SS \fB--stop-signal\fP=\fIsignal\fP
سیگنال برای متوقف کردن کانتینر. پیش‌فرض \fBSIGTERM\fP است.

.SS \fB--stop-timeout\fP=\fIseconds\fP
مهلت زمانی (تایم‌اوت) برای توقف کانتینر به ثانیه. پیش‌فرض \fB10\fP است. اتصالات از راه دور از تنظیمات containers.conf محلی برای مقادیر پیش‌فرض استفاده می‌کنند.

.SS \fB--subgidname\fP=\fIname\fP
اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت دارای \fIname\fP در فایل \fI/etc/subgid\fP\&. هنگام اجرای بدون ریشه (rootless)، کاربر به مجوزهای لازم برای استفاده از نگاشت نیاز دارد. به \fBsubgid\fP(5) مراجعه کنید. این فلگ با \fB--userns\fP و \fB--gidmap\fP تداخل دارد. همراه با \fB--gidmap\fP به گونه‌ای عمل می‌کند که گویی \fB--gidmap\fP با تمام نگاشت‌های گروه \fIname\fP در \fI/etc/subgid\fP ارسال شده است.

.SS \fB--subuidname\fP=\fIname\fP
اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت دارای \fIname\fP در فایل \fI/etc/subuid\fP\&. هنگام اجرای بدون ریشه (rootless)، کاربر به مجوزهای لازم برای استفاده از نگاشت نیاز دارد. به \fBsubuid\fP(5) مراجعه کنید. این فلگ با \fB--userns\fP و \fB--uidmap\fP تداخل دارد. همراه با \fB--uidmap\fP به گونه‌ای عمل می‌کند که گویی \fB--uidmap\fP با تمام نگاشت‌های کاربر \fIname\fP در \fI/etc/subuid\fP ارسال شده است.

.SS \fB--sysctl\fP=\fIname=value\fP
پیکربندی پارامترهای فضای‌نام‌گذاری‌شده هسته در زمان اجرا.

.PP
برای فضای نام IPC، مقادیر sysctl زیر مجاز هستند:
.IP \(bu 2
kernel.msgmax
.IP \(bu 2
kernel.msgmnb
.IP \(bu 2
kernel.msgmni
.IP \(bu 2
kernel.sem
.IP \(bu 2
kernel.shmall
.IP \(bu 2
kernel.shmmax
.IP \(bu 2
kernel.shmmni
.IP \(bu 2
kernel.shm_rmid_forced
.IP \(bu 2
مواردی از sysctl که با fs.mqueue.* شروع می‌شوند

.PP
نکته: در صورت استفاده از گزینه \fB--ipc=host\fP، مقادیر sysctl بالا مجاز نیستند.

.PP
برای فضای نام شبکه، تنها مقادیر sysctl که با net.* شروع می‌شوند مجاز هستند.

.PP
نکته: در صورت استفاده از گزینه \fB--network=host\fP، مقادیر sysctl بالا مجاز نیستند.

.SS \fB--systemd\fP=\fItrue\fP | \fIfalse\fP | \fIalways\fP
اجرای کانتینر در حالت systemd. مقدار پیش‌فرض \fBtrue\fP است.
.IP \(bu 2
مقدار \fBtrue\fP حالت systemd را تنها زمانی فعال می‌کند که دستور اجراشده درون کانتینر \fIsystemd\fP، \fI/usr/sbin/init\fP، \fI/sbin/init\fP یا \fI/usr/local/sbin/init\fP باشد.
.IP \(bu 2
مقدار \fBfalse\fP حالت systemd را غیرفعال می‌کند.
.IP \(bu 2
مقدار \fBalways\fP فعال بودن حالت systemd را تحمیل می‌کند.

.PP
اجرای کانتینر در حالت systemd تغییرات زیر را ایجاد می‌کند:
.IP \(bu 2
پادمن سیستم‌فایل‌های tmpfs را روی دایرکتوری‌های زیر سوار می‌کند
.RS
.IP \(bu 2
\fI/run\fP
.IP \(bu 2
\fI/run/lock\fP
.IP \(bu 2
\fI/tmp\fP
.IP \(bu 2
\fI/sys/fs/cgroup/systemd\fP (در سیستم با cgroup v1)
.IP \(bu 2
\fI/var/lib/journal\fP
.RE
.IP \(bu 2
پادمن سیگنال پیش‌فرض توقف را روی \fBSIGRTMIN+3\fP تنظیم می‌کند.
.IP \(bu 2
پادمن متغیر محیطی \fBcontainer_uuid\fP را در کانتینر روی ۳۲ کاراکتر اول شناسه کانتینر تنظیم می‌کند.
.IP \(bu 2
پادمن هنگام اجرا با \fB--privileged\fP کنسول‌های مجازی (\fI/dev/tty\\d+\fP) را سوار نمی‌کند.
.IP \(bu 2
در cgroup v2 مسیر \fI/sys/fs/cgroup\fP به صورت قابل‌نوشتن سوار می‌شود.

.PP
این به systemd اجازه می‌دهد درون یک کانتینر محدودشده بدون نیاز به هیچ تغییری اجرا شود.

.PP
توجه داشته باشید که در سیستم‌های \fBSELinux\fP، سیستم‌فایل cgroup تلاش می‌کند روی آن بنویسد. نوشتن کانتینرها روی سیستم‌فایل cgroup به طور پیش‌فرض رد می‌شود. بولی \fBcontainer_manage_cgroup\fP باید فعال باشد تا این کار در یک سیستم با تفکیک SELinux مجاز گردد.

.EX
setsebool -P container_manage_cgroup true
.EE

.SS \fB--timeout\fP=\fIseconds\fP
حداکثر زمانی که یک کانتینر مجاز به اجرا است قبل از اینکه conmon سیگنال kill را برای آن بفرستد. به طور پیش‌فرض کانتینرها تا زمان خروج یا توقف توسط \fBpodman stop\fR اجرا می‌شوند.

.SS \fB--tls-verify\fP
الزام HTTPS و اعتبارسنجی گواهی‌ها هنگام تماس با رجیستری‌ها (پیش‌فرض: \fBtrue\fP). اگر صریحاً روی \fBtrue\fP تنظیم شود، اعتبارسنجی TLS انجام می‌شود. اگر روی \fBfalse\fP تنظیم شود، اعتبارسنجی TLS انجام نمی‌شود. اگر مشخص نشود، اعتبارسنجی TLS اعمال می‌شود مگر اینکه رجیستری هدف در \fBcontainers-registries.conf(5)\fP به عنوان یک رجیستری ناامن فهرست شده باشد.

.SS \fB--tmpfs\fP=\fIfs\fP
ایجاد یک مانت tmpfs.

.PP
سوار کردن یک سیستم‌فایل موقت (\fBtmpfs\fP) درون کانتینر، برای نمونه:

.EX
$ podman run -d --tmpfs /tmp:rw,size=787448k,mode=1777 my_image
.EE

.PP
این دستور یک \fBtmpfs\fP را در مسیر \fI/tmp\fP درون کانتینر سوار می‌کند. گزینه‌های مانت پشتیبانی‌شده همان فلگ‌های پیش‌فرض مانت در لینوکس هستند. اگر گزینه‌ای مشخص نشود، سیستم از گزینه‌های زیر استفاده می‌کند:
\fBrw,noexec,nosuid,nodev\fP\&.

.PP
به طور پیش‌فرض، پادمن گزینه \fBtmpcopyup\fP را در مانت‌های tmpfs فعال می‌کند که محتوای دایرکتوری ایمیج زیرین را پیش از سوار کردن در tmpfs کپی می‌کند. این همچنین زمانی اعمال می‌شود که مقصد tmpfs درون یک حجم یا مانت بایند باشد: فایل‌های مانت والد در tmpfs کپی می‌شوند، بنابراین محتوای والد همچنان قابل مشاهده می‌ماند. برای سوار کردن یک tmpfs خالی که زیردرخت مانت والد را بپوشاند (shadow)، از گزینه \fBnotmpcopyup\fP استفاده کنید:

.EX
$ podman run --volume myvolume:/data --tmpfs /data/sub:notmpcopyup my_image
.EE

.SS \fB--tty\fP, \fB-t\fP
تخصیص یک شبه‌ترمینال (pseudo-TTY). پیش‌فرض \fBfalse\fP است.

.PP
هنگامی که روی \fBtrue\fP تنظیم شود، پادمن یک pseudo-tty اختصاص داده و به ورودی استاندارد کانتینر متصل می‌شود. این می‌تواند برای نمونه برای اجرای یک شل تعاملی یک‌بارمصرف استفاده شود.

.PP
\fBنکته:\fP فلگ --tty مانع از تغییر مسیر (redirection) خروجی استاندارد می‌شود. این فلگ STDOUT و STDERR را ترکیب می‌کند، می‌تواند کاراکترهای کنترلی درج کند، و پایپ‌ها را معلق سازد. این گزینه تنها در زمان اجرای تعاملی در ترمینال استفاده می‌شود. هنگام ارسال ورودی به پادمن، تنها از -i استفاده کنید نه -it.

.EX
echo "asdf" | podman run --rm -i someimage /bin/cat
.EE

.SS \fB--tz\fP=\fItimezone\fP
تنظیم منطقه زمانی (تایم‌زون) در کانتینر. این فلگ مناطق زمانی بر پایه ناحیه، زمان GMT و همچنین \fBlocal\fR را می‌پذیرد که منطقه زمانی درون کانتینر را مطابق با ماشین میزبان تنظیم می‌کند. برای مناطق زمانی معتبر به \fB/usr/share/zoneinfo/\fR مراجعه کنید.
اتصالات راه دور از containers.conf محلی برای مقادیر پیش‌فرض استفاده می‌کنند.

.SS \fB--uidmap\fP=\fI[flags]container_uid:from_uid[:amount]\fP
اجرای کانتینر در یک فضای نام کاربری جدید با استفاده از نگاشت UID ارائه‌شده. این گزینه با گزینه‌های \fB--userns\fP و \fB--subuidname\fP تداخل دارد. این گزینه روشی برای نگاشت UIDهای میزبان به UIDهای کانتینر فراهم می‌آورد. می‌تواند چندین بار برای نگاشت بازه‌های مختلف ارسال شود.

.PP
مقادیر ممکن برای \fIflags\fP اختیاری در ادامه این صفحه بررسی شده‌اند. مقدار \fIamount\fP اختیاری است و در صورت عدم ارائه، \fB1\fP فرض می‌شود.

.PP
مقدار \fIfrom_uid\fP بر اساس کاربری است که دستور را اجرا می‌کند، اعم از کاربر ریشه‌دار یا بدون ریشه.
.IP \(bu 2
کاربر ریشه‌دار (rootful): [\fIflags\fP]\fIcontainer_uid\fP:\fIhost_uid\fP[:\fIamount\fP]
.IP \(bu 2
کاربر بدون ریشه (rootless): [\fIflags\fP]\fIcontainer_uid\fP:\fIintermediate_uid\fP[:\fIamount\fP]

.PP
\fBنگاشت‌های با ریشه (Rootful)\fR

.PP
هنگامی که \fBpodman run\fP توسط کاربر ممتاز فراخوانی می‌شود، گزینه \fB--uidmap\fP به عنوان یک نگاشت مستقیم بین UIDهای میزبان و UIDهای کانتینر عمل می‌کند.

.PP
UID میزبان -> UID کانتینر

.PP
مقدار \fIamount\fP تعداد UIDهای متوالی مورد نگاشت را مشخص می‌کند. برای نمونه اگر \fIamount\fP برابر با \fB4\fP باشد نگاشت به این شکل خواهد بود:

.TS
allbox;
l l 
l l .
\fBhost UID\fP	\fBcontainer UID\fP
\fIfrom_uid\fP	\fIcontainer_uid\fP
\fIfrom_uid\fP + 1	\fIcontainer_uid\fP + 1
\fIfrom_uid\fP + 2	\fIcontainer_uid\fP + 2
\fIfrom_uid\fP + 3	\fIcontainer_uid\fP + 3
.TE

.PP
\fBنگاشت‌های بدون ریشه (Rootless)\fR

.PP
هنگامی که \fBpodman run\fP توسط کاربر غیرممتاز (یعنی در حالت بدون ریشه) فراخوانی می‌شود، مقدار \fIfrom_uid\fP به عنوان "UID واسط" (intermediate UID) تفسیر می‌شود. در حالت بدون ریشه، UIDهای میزبان مستقیماً به UIDهای کانتینر نگاشت نمی‌شوند. در عوض نگاشت در دو مرحله صورت می‌گیرد:

.PP
UID میزبان -> UID واسط -> UID کانتینر

.PP
گزینه \fB--uidmap\fP تنها بر مرحله دوم نگاشت اثر می‌گذارد.

.PP
مرحله اول نگاشت توسط پادمن از محتوای فایل \fI/etc/subuid\fP و UID کاربری که پادمن را فراخوانی کرده به دست می‌آید.

.PP
مرحله نخست نگاشت:

.TS
allbox;
l l 
l l .
\fBhost UID\fP	\fBintermediate UID\fP
UID for Podman user	0
1st subordinate UID	1
2nd subordinate UID	2
3rd subordinate UID	3
nth subordinate UID	n
.TE

.PP
برای اینکه کاربر بتواند از UIDهای واسط بزرگتر از صفر استفاده کند، باید UIDهای زیرمجموعه در \fI/etc/subuid\fP پیکربندی شده باشند. به \fBsubuid\fP(5) مراجعه کنید.

.PP
مرحله دوم نگاشت با \fB--uidmap\fP پیکربندی می‌شود.

.PP
اگر برای نمونه \fIamount\fP برابر \fB5\fP باشد، مرحله دوم نگاشت به صورت زیر است:

.TS
allbox;
l l 
l l .
\fBintermediate UID\fP	\fBcontainer UID\fP
\fIfrom_uid\fP	\fIcontainer_uid\fP
\fIfrom_uid\fP + 1	\fIcontainer_uid\fP + 1
\fIfrom_uid\fP + 2	\fIcontainer_uid\fP + 2
\fIfrom_uid\fP + 3	\fIcontainer_uid\fP + 3
\fIfrom_uid\fP + 4	\fIcontainer_uid\fP + 4
.TE

.PP
هنگام اجرا در حالت بدون ریشه، پادمن از تمامی بازه‌های پیکربندی‌شده در فایل \fI/etc/subuid\fP استفاده می‌کند.

.PP
شناسه کاربر جاری به UID=0 در فضای نام کاربری بدون ریشه نگاشت می‌شود. هر بازه اضافی پس از آن به صورت متوالی اضافه می‌شود:

.TS
allbox;
l l l 
l l l .
\fBhost\fP	\fBrootless user namespace\fP	\fBlength\fP
$UID	0	1
1	$FIRST_RANGE_ID	$FIRST_RANGE_LENGTH
1+$FIRST_RANGE_LENGTH	$SECOND_RANGE_ID	$SECOND_RANGE_LENGTH
.TE

.PP
\fBارجاع به شناسه میزبان از فضای نام والد\fR

.PP
به عنوان یک کاربر بدون ریشه، شناسه میزبان داده‌شده در \fB--uidmap\fP یا \fB--gidmap\fP از \fIفضای نام واسط\fP تولیدشده توسط پادمن نگاشت می‌شود. گاهی اوقات مطلوب است که مستقیماً به \fIفضای نام میزبان\fP ارجاع داده شود. این کار به صورت دستی با اجرای \fBpodman unshare cat /proc/self/gid_map\fR، یافتن شناسه میزبان مورد نظر در ستون دوم خروجی، و دریافت شناسه واسط متناظر از ستون اول امکان‌پذیر است.

.PP
پادمن می‌تواند همه این کارها را با قرار دادن نماد \fB@\fR قبل از شناسه میزبان در نگاشت انجام دهد. برای نمونه با مشخص کردن \fB--gidmap 100000:@2000:1\fR، پادمن شناسه واسط متناظر با شناسه میزبان \fB2000\fR را جستجو کرده و شناسه واسط یافت‌شده را به شناسه کانتینر \fB100000\fR نگاشت می‌کند. شناسه میزبان داده‌شده باید قبلاً زیرمجموعه شده باشد (در غیر این صورت اصلاً به فضای واسط نگاشت نمی‌شد).

.PP
اگر طول بیشتر از یک باشد، مثلاً با \fB--gidmap 100000:@2000:2\fR، پادمن شناسه‌های میزبان \fB2000\fR و \fB2001\fR را به ترتیب به \fB100000\fR و \fB100001\fR نگاشت می‌کند، صرف‌نظر از اینکه نگاشت واسط چگونه تعریف شده باشد.

.PP
\fBگسترش نگاشت‌های قبلی\fR

.PP
برخی اصلاحات نگاشت ممکن است پیچیده و پرزحمت باشند. برای نمونه، کاربری با نگاشتی مانند \fB--gidmap="0:0:65000"\fR شروع می‌کند که باید به گونه‌ای تغییر یابد که شناسه والد \fB1\fR در عوض به شناسه کانتینر \fB100000\fR نگاشت شود و شناسه کانتینر \fB1\fR بدون تخصیص باقی بماند. دستور \fB--gidmap\fP مربوطه تبدیل می‌شود به: \fB--gidmap="0:0:1" --gidmap="2:2:65534" --gidmap="100000:1:1"\fR\&.

.PP
این نشانه‌گذاری را می‌توان با استفاده از فلگ \fB+\fR ساده کرد که نگاشت‌های قبلی را شکسته و هرگونه انتساب تداخل‌دار با نگاشت ارائه‌شده را حذف می‌کند. این فلگ قبل از شناسه کانتینر به این صورت ارائه می‌شود: \fB--gidmap="0:0:65000" --gidmap="+100000:1:1"\fR

.TS
allbox;
l l l 
l l l .
\fBFlag\fP	\fBExample\fP	\fBDescription\fP
\fB+\fR	\fB+100000:1:1\fR	گسترش نگاشت قبلی
.TE

.PP
این نشانه‌گذاری به ایجاد شکاف در انتساب منجر می‌شود، بنابراین ممکن است پس از آن پر کردن شکاف‌ها مناسب باشد: \fB--gidmap="0:0:65000" --gidmap="+100000:1:1" --gidmap="1:65001:1"\fR

.PP
یک مورد استفاده خاص برای این فلگ در زمینه کاربران بدون ریشه است. کاربر بدون ریشه می‌تواند نگاشت‌ها را با فلگ \fB+\fR مانند \fB--gidmap="+100000:1:1"\fR مشخص کند. سپس پادمن شکاف‌ها را با شروع از صفر با تمامی شناسه‌های واسط باقیمانده پر می‌کند. این زمانی کاراست که کاربر بخواهد یک شناسه واسط خاص را به یک شناسه کانتینر نگاشت کند و اجازه دهد مابقی شناسه‌های زیرمجموعه به دلخواه توسط پادمن نگاشت شوند.

.PP
\fBارسال تنها یکی از گزینه‌های --uidmap یا --gidmap\fR

.PP
معمولاً شناسه‌های کاربر و گروه زیرمجموعه به صورت همزمان تخصیص می‌یابند و برای هر کاربری شناسه‌های کاربر زیرمجموعه با شناسه‌های گروه زیرمجموعه مطابقت دارد. برای سهولت، اگر تنها یکی از گزینه‌های \fB--uidmap\fP یا \fB--gidmap\fP داده شود، پادمن فرض می‌کند نگاشت به هر دو UID و GID اشاره دارد و نگاشت داده‌شده را برای هر دو اعمال می‌کند. اگر تنها یکی از این دو مقدار نیاز به تغییر داشته باشد، نگاشت‌ها باید شامل فلگ‌های \fBu\fR یا \fBg\fR باشند تا مشخص شود تنها برای UIDها یا GIDها اعمال می‌شوند و نباید کپی گردند.

.TS
allbox;
l l l 
l l l .
\fBflag\fP	\fBExample\fP	\fBDescription\fP
\fBu\fR	\fBu20000:2000:1\fR	T{
نگاشت تنها برای UIDها اعمال می‌شود
T}
\fBg\fR	\fBg10000:1000:1\fR	T{
نگاشت تنها برای GIDها اعمال می‌شود
T}
.TE

.PP
برای نمونه با فرض دستور:

.EX
podman run --gidmap "0:0:1000" --gidmap "g2000:2000:1"
.EE

.PP
از آنجا که هیچ \fB--uidmap\fP داده نشده است، مقدار \fB--gidmap\fP در \fB--uidmap\fP کپی می‌شود و دستوری معادل زیر ایجاد می‌کند:

.EX
podman run --gidmap "0:0:1000" --gidmap "2000:2000:1" --uidmap "0:0:1000"
.EE

.PP
گزینه \fB--gidmap "g2000:2000:1"\fR از فلگ \fBg\fR استفاده کرده و بنابراین در \fB--uidmap\fP کپی نشده است.

.PP
\fBنگاشت بدون ریشه GIDهای اضافی میزبان\fR

.PP
یک کاربر بدون ریشه ممکن است مایل باشد یک گروه میزبان خاص را که قبلاً در \fI/etc/subgid\fP زیرمجموعه شده است، بدون تعیین مابقی نگاشت، نگاشت کند.

.PP
این کار با دستور \fB--gidmap "+g\fIcontainer_gid\fP:@\fIhost_gid\fP"\fP انجام می‌شود.

.PP
که در آن:
.IP \(bu 2
شناسه GID میزبان از طریق نماد \fB@\fR داده می‌شود
.IP \(bu 2
نگاشت این GID به لطف فلگ \fBg\fR در \fB--usermap\fP کپی نمی‌شود.
.IP \(bu 2
مابقی شناسه‌های کانتینر با شروع از 0 تا n، با تمامی GIDهای زیرمجموعه باقیمانده، به لطف فلگ \fB+\fR نگاشت خواهند شد.

.PP
برای نمونه اگر کاربری متعلق به گروه \fB2000\fR باشد و آن گروه به آن کاربر زیرمجموعه شده باشد (با \fBusermod --add-subgids 2000-2000 $USER\fR)، کاربر می‌تواند گروه را با این دستور به کانتینر نگاشت کند: \fB--gidmap=+g100000:@2000\fP\&.

.PP
اگر این نگاشت با گزینه \fB--group-add=keep-groups\fP ترکیب شود، فرایند در کانتینر به گروه \fB100000\fR تعلق خواهد داشت و فایل‌های متعلق به گروه \fB2000\fR در میزبان، درون کانتینر متعلق به گروه \fB100000\fR به نظر می‌رسند.

.EX
podman run --group-add=keep-groups --gidmap="+g100000:@2000" ...
.EE

.PP
\fBعدم وجود UIDهای زیرمجموعه\fR

.PP
حتی اگر کاربری هیچ UID زیرمجموعه‌ای در \fI/etc/subuid\fP نداشته باشد، با اجرای \fBpodman run --uidmap $container_uid:0:1 --user $container_uid ...\fR می‌توان از \fB--uidmap\fP برای نگاشت UID عادی کاربر به یک UID کانتینر استفاده کرد.

.PP
\fBپادها (Pods)\fR

.PP
گزینه \fB--uidmap\fP نمی‌تواند همراه با گزینه \fB--pod\fP فراخوانی شود زیرا uidmap را نمی‌توان در سطح کانتینر هنگامی که در پاد است تنظیم نمود.

.SS \fB--ulimit\fP=\fIoption\fP
گزینه‌های ulimit. مقادیر ulimits را درون کانتینر تنظیم می‌کند.

.PP
فلگ --ulimit با یک حد نرم (soft) و سخت (hard) در قالب =[:]. برای نمونه:

.PP
$ podman run --ulimit nofile=1024:1024 --rm ubi9 ulimit -n
1024

.PP
مقدار -1 را برای حد نرم یا سخت تنظیم کنید تا حد را روی حداکثر حد فرایند جاری قرار دهد. در حالت rootful این معمولاً نامحدود است.

.PP
اگر nofile و nproc تنظیم نشده باشند، مقدار پیش‌فرض 1048576 استفاده خواهد شد، مگر اینکه در containers.conf(5) لغو شود. با این حال، اگر مقدار پیش‌فرض از حد سخت کاربر بدون ریشه جاری فراتر رود، حد سخت جاری اعمال خواهد شد.

.PP
از \fBhost\fP برای کپی کردن پیکربندی جاری از میزبان استفاده کنید.

.PP
از nproc با فلگ ulimit استفاده نکنید زیرا لینوکس از nproc برای تنظیم حداکثر تعداد فرایندهای در دسترس یک کاربر استفاده می‌کند، نه یک کانتینر.

.PP
از گزینه --pids-limit برای تغییر کنترل cgroup به منظور محدود کردن تعداد فرایندهای درون کانتینر استفاده نمایید.

.SS \fB--umask\fP=\fIumask\fP
تنظیم umask درون کانتینر. پیش‌فرض \fB0022\fR است. اتصالات از راه دور از \fBcontainers.conf\fR محلی برای مقادیر پیش‌فرض استفاده می‌کنند.

.SS \fB--unsetenv\fP=\fIenv\fP
حذف تنظیم متغیرهای محیطی پیش‌فرض برای کانتینر. متغیرهای محیطی پیش‌فرض شامل متغیرهای ارائه‌شده توسط خود پادمن، متغیرهای پیکربندی‌شده توسط ایمیج و متغیرهای محیطی از containers.conf هستند.

.SS \fB--unsetenv-all\fP
حذف تنظیم تمام متغیرهای محیطی پیش‌فرض برای کانتینر. متغیرهای محیطی پیش‌فرض شامل متغیرهای ارائه‌شده توسط خود پادمن، متغیرهای پیکربندی‌شده توسط ایمیج و متغیرهای محیطی از containers.conf هستند.

.SS \fB--user\fP, \fB-u\fP=\fIuser[:group]\fP
تنظیم نام کاربری یا UID مورد استفاده و اختیاری، نام گروه یا GID برای دستور مشخص‌شده. هر دو مقدار \fIuser\fP و \fIgroup\fP می‌توانند نمادین یا عددی باشند.

.PP
بدون این آرگومان، دستور با کاربری که در ایمیج کانتینر مشخص شده اجرا می‌شود. مگر اینکه توسط دستور \fBUSER\fR در Containerfile یا مقداری که به این گزینه داده می‌شود لغو گردد، این کاربر عموماً به root پیش‌فرض می‌شود.

.PP
هنگامی که فضای نام کاربری استفاده نمی‌شود، UID و GID استفاده‌شده در کانتینر و روی میزبان یکسان هستند. با این حال، هنگامی که فضاهای نام کاربری در حال استفاده هستند، UID و GID درون کانتینر ممکن است متناظر با UID و GID دیگری روی میزبان باشند. در کانتینرهای بدون ریشه، برای نمونه، یک فضای نام کاربری همواره استفاده می‌شود و root در کانتینر به طور پیش‌فرض متناظر با UID و GID کاربری است که پادمن را فراخوانی کرده است.

.SS \fB--userns\fP=\fImode\fP
تنظیم حالت فضای نام کاربری برای کانتینر.

.PP
اگر \fB--userns\fR تنظیم نشود، مقدار پیش‌فرض به شرح زیر تعیین می‌شود:
- اگر \fB--pod\fR تنظیم شده باشد، \fB--userns\fR نادیده گرفته شده و از فضای نام کاربری پاد استفاده می‌شود.
- اگر متغیر محیطی \fBPODMAN_USERNS\fP تنظیم شده باشد مقدار آن استفاده می‌شود.
- اگر \fBuserns\fR در \fBcontainers.conf\fR مشخص شده باشد این مقدار استفاده می‌شود.
- در غیر این صورت، \fB--userns=host\fR فرض می‌شود.

.PP
گزینه \fB--userns=""\fR (یعنی یک رشته خالی) نام مستعاری برای \fB--userns=host\fR است.

.PP
این گزینه با \fB--gidmap\fP، \fB--uidmap\fP، \fB--subuidname\fP و \fB--subgidname\fP ناسازگار است.

.PP
نگاشت‌های کلیدی کاربر بدون ریشه با --userns=Key:

.TS
allbox;
l l l 
l l l .
\fBKey\fP	\fBHost User\fP	\fBContainer User\fP
auto	$UID	T{
nil (UID کاربر میزبان به کانتینر نگاشت نمی‌شود.)
T}
host	$UID	T{
0 (حساب کاربر پیش‌فرض به کاربر root در کانتینر نگاشت می‌شود.)
T}
keep-id	$UID	T{
$UID (نگاشت حساب کاربر به همان UID درون کانتینر.)
T}
keep-id:uid=200,gid=210	$UID	T{
200:210 (نگاشت حساب کاربر به مقادیر UID و GID مشخص‌شده درون کانتینر.)
T}
nomap	$UID	T{
nil (UID کاربر میزبان به کانتینر نگاشت نمی‌شود.)
T}
.TE

.PP
مقادیر مجاز \fImode\fP عبارتند از:

.PP
\fBauto\fP[:\fIOPTIONS,...\fP]: ایجاد خودکار یک فضای نام کاربری منحصر‌به‌فرد.
.IP \(bu 2
\fBحالت ریشه‌دار (rootful)\fR: فلگ \fB--userns=auto\fR مستلزم آن است که نام کاربری \fBcontainers\fP در فایل‌های /etc/subuid و /etc/subgid مشخص شده باشد، با بازه‌ای استفاده‌نشده از شناسه‌های کاربر زیرمجموعه که کانتینرهای پادمن مجاز به تخصیص آن‌ها هستند. مثال: \fBcontainers:2147483647:2147483648\fR\&.
.IP \(bu 2
\fBحالت بدون ریشه (rootless)\fR: بازه کاربران از فایل‌های /etc/subuid و /etc/subgid استفاده خواهد شد. توجه داشته باشید اجرای یک کانتینر واحد بدون استفاده از --userns=auto تمام بازه UIDها را مصرف کرده و اجازه تقسیم‌بندی بیشتر را نمی‌دهد. به subuid(5) مراجعه کنید.

.PP
پادمن بازه‌های منحصربه‌فردی از UIDها و GIDها را از شناسه‌های کاربر زیرمجموعه \fBcontainers\fR تخصیص می‌دهد. اندازه بازه‌ها بر اساس تعداد UIDهای مورد نیاز در ایمیج است. تعداد UIDها و GIDها را می‌توان با گزینه \fBsize\fR لغو کرد.

.PP
گزینه \fB--userns=keep-id\fR از تمامی subuidها و subgidهای کاربر استفاده می‌کند.
گزینه \fB--userns=nomap\fR از تمامی subuidها و subgidهای کاربر به جز شناسه خود کاربر استفاده می‌کند.
استفاده از \fB--userns=auto\fR هنگام شروع کانتینرهای جدید تا زمانی که کانتینرهایی وجود داشته باشند که با \fB--userns=nomap\fR یا \fB--userns=keep-id\fR بدون محدود کردن اندازه فضای نام کاربری شروع شده‌اند کار نخواهد کرد.

.PP
گزینه‌های معتبر \fBauto\fR:
.IP \(bu 2
\fIgidmapping\fP=\fICONTAINER_GID:HOST_GID:SIZE\fP: برای اجبار به وجود یک نگاشت GID در فضای نام کاربری.
.IP \(bu 2
\fIsize\fP=\fISIZE\fP: برای مشخص کردن اندازه صریح برای فضای نام کاربری خودکار. مثلاً \fB--userns=auto:size=8192\fR\&. اگر \fBsize\fR مشخص نشود، گزینه \fBauto\fR اندازه‌ای را برای فضای نام کاربری تخمین می‌زند.
.IP \(bu 2
\fIuidmapping\fP=\fICONTAINER_UID:HOST_UID:SIZE\fP: برای اجبار به وجود یک نگاشت UID در فضای نام کاربری.

.PP
شناسه UID و GID میزبان در \fIgidmapping\fP و \fIuidmapping\fP می‌توانند اختیاری دارای پیشوند نماد \fB@\fR باشند. در این حالت، پادمن شناسه واسط متناظر با شناسه میزبان را جستجو کرده و شناسه واسط یافت‌شده را به شناسه کانتینر نگاشت می‌کند. برای جزئیات به \fB--uidmap\fP مراجعه کنید.

.PP
\fBcontainer:\fP\fIid\fP: پیوستن به فضای نام کاربری کانتینر مشخص‌شده.

.PP
\fBhost\fP یا \fB""\fP (رشته خالی): اجرا در فضای نام کاربری فراخواننده. فرایندهای در حال اجرا در کانتینر همان امتیازاتی را روی میزبان دارند که هر فرایند دیگری که توسط کاربر فراخواننده اجرا شود دارد.

.PP
\fBkeep-id\fP: یک فضای نام کاربری ایجاد می‌کند که در آن UID:GID کاربر جاری به همان مقادیر درون کانتینر نگاشت می‌شوند. برای کانتینرهای ایجادشده توسط root، نگاشت جاری درون یک فضای نام کاربری جدید ایجاد می‌شود.

.PP
علاوه بر این، فرایند init درون کانتینر تحت UID کاربر جاری اجرا خواهد شد. این رفتار دستورالعمل \fBUSER\fR ایمیج را لغو می‌کند مگر اینکه صریحاً \fB--user\fR را تنظیم کرده باشید.

.PP
گزینه‌های معتبر \fBkeep-id\fR:
.IP \(bu 2
\fIuid\fP=UID: لغو UID درون کانتینر که برای نگاشت کاربر جاری استفاده می‌شود.
.IP \(bu 2
\fIgid\fP=GID: لغو GID درون کانتینر که برای نگاشت کاربر جاری استفاده می‌شود.
.IP \(bu 2
\fIsize\fP=SIZE: لغو اندازه فضای نام کاربری پیکربندی‌شده. برای جلوگیری از اشباع تمام شناسه‌های موجود مفید است. هنگام اجرا به عنوان root پشتیبانی نمی‌شود.

.PP
\fBnomap\fP: یک فضای نام کاربری ایجاد می‌کند که در آن UID:GID کاربر بدون ریشه جاری به داخل کانتینر نگاشت نمی‌شوند. این گزینه برای کانتینرهای ایجادشده توسط کاربر root مجاز نیست.

.PP
\fBns:\fP\fInamespace\fP: اجرای کانتینر در فضای نام کاربری موجودِ مشخص‌شده.

.SS \fB--uts\fP=\fImode\fP
تنظیم حالت فضای نام UTS برای کانتینر. مقادیر زیر پشتیبانی می‌شوند:
.IP \(bu 2
\fBhost\fP: استفاده از فضای نام UTS میزبان درون کانتینر.
.IP \(bu 2
\fBprivate\fP: ایجاد یک فضای نام جدید برای کانتینر (پیش‌فرض).
.IP \(bu 2
\fBns:[path]\fP: اجرای کانتینر در فضای نام UTS موجودِ مشخص‌شده.
.IP \(bu 2
\fBcontainer:[container]\fP: پیوستن به فضای نام UTS کانتینر مشخص‌شده.

.SS \fB--variant\fP=\fIVARIANT\fP
استفاده از \fIVARIANT\fP به جای گونه معماری پیش‌فرض ایمیج کانتینر. برخی ایمیج‌ها می‌توانند از چندین گونه از معماری‌های arm استفاده کنند، مانند arm/v5 و arm/v7.

.SS \fB--volume\fP, \fB-v\fP=\fI[[SOURCE-VOLUME|HOST-DIR:]CONTAINER-DIR[:OPTIONS]]\fP
ایجاد یک مانت بایند (bind mount). اگر \fB-v /HOST-DIR:/CONTAINER-DIR\fR مشخص شود، پادمن \fB/HOST-DIR\fR را از میزبان در مسیر \fB/CONTAINER-DIR\fR در کانتینر پادمن به صورت بایند سوار می‌کند. به طور مشابه، \fB-v SOURCE-VOLUME:/CONTAINER-DIR\fR حجم نام‌گذاری‌شده را از میزبان به درون کانتینر سوار می‌کند. اگر چنین حجم نام‌گذاری‌شده‌ای وجود نداشته باشد، پادمن یکی می‌سازد. از گزینه \fBnocreate\fP می‌توان برای غیرفعال کردن این رفتار و الزام به وجود قبلی حجم استفاده کرد. اگر هیچ مبدائی داده نشود، حجم به عنوان یک حجم ناشناس با نامی به صورت تصادفی تولیدشده ساخته می‌شود، و هنگامی که کانتینر از طریق فلگ \fB--rm\fR یا دستور \fBpodman rm --volumes\fR حذف شود از بین می‌رود.

.PP
(توجه داشته باشید هنگام استفاده از کلاینت راه دور، از جمله ماشین‌های مک و ویندوز (به استثنای WSL2)، حجم‌ها از سرور از راه دور سوار می‌شوند، نه لزوماً ماشین کلاینت.)

.PP
مقدار \fIOPTIONS\fP لیستی جداشده با کاما است و می‌تواند یک یا چند مورد از موارد زیر باشد:
.IP \(bu 2
\fBrw\fP|\fBro\fP
.IP \(bu 2
\fBz\fP|\fBZ\fP
.IP \(bu 2
[\fBO\fP]
.IP \(bu 2
[\fBU\fP]
.IP \(bu 2
[\fBno\fP]\fBcopy\fP
.IP \(bu 2
[\fBno\fP]\fBdev\fP
.IP \(bu 2
[\fBno\fP]\fBexec\fP
.IP \(bu 2
[\fBno\fP]\fBsuid\fP
.IP \(bu 2
[\fBr\fP]\fBbind\fP
.IP \(bu 2
[\fBr\fP]\fBshared\fP|[\fBr\fP]\fBslave\fP|[\fBr\fP]\fBprivate\fP[\fBr\fP]\fBunbindable\fP [1]
\[la]#Footnote1\[ra]
.IP \(bu 2
\fBidmap\fP[=\fBoptions\fP]
.IP \(bu 2
\fBnocreate\fP

.PP
مسیر \fBCONTAINER-DIR\fR باید یک مسیر مطلق مانند \fB/src/docs\fR باشد. حجم در این دایرکتوری درون کانتینر سوار می‌شود.

.PP
اگر مبدا حجم مشخص شود، باید مسیری روی میزبان یا نام یک حجم نام‌گذاری‌شده باشد. مسیرهای میزبان می‌توانند مطلق یا نسبی باشند؛ مسیرهای نسبی نسبت به دایرکتوری‌ای که پادمن در آن اجرا می‌شود حل و فصل می‌گردند. اگر مبدا وجود نداشته باشد، پادمن خطایی برمی‌گرداند. کاربران باید فایل‌ها یا دایرکتوری‌های مبدا را از قبل ایجاد کنند.

.PP
هر مبدائی که با \fB\&.\fR یا \fB/\fR آغاز نشود به عنوان نام یک حجم نام‌گذاری‌شده تلقی می‌شود. اگر حجمی با آن نام وجود نداشته باشد، ایجاد می‌شود. حجم‌های ایجادشده با نام، ناشناس نیستند و با گزینه \fB--rm\fR و دستور \fBpodman rm --volumes\fR حذف نمی‌شوند.

.PP
گزینه \fBnocreate\fP را می‌توان برای حجم‌های نام‌گذاری‌شده مشخص کرد تا از ایجاد خودکار حجم جلوگیری شود. اگر \fBnocreate\fP تنظیم شود و حجم وجود نداشته باشد، پادمن به جای ایجاد حجم خطا برمی‌گرداند. این زمانی مفید است که بخواهید اطمینان حاصل کنید حجم قبل از استفاده صریحاً ایجاد شده است.

.EX
$ podman run -v myvolume:/data:nocreate alpine
.EE

.PP
چندین گزینه \fB-v\fP را مشخص کنید تا یک یا چند حجم را درون کانتینر سوار کنید.

.PP
\fBمانت‌های حجم محافظت‌شده در برابر نوشتن\fR

.PP
گزینه \fB:ro\fP یا \fB:rw\fP را برای سوار کردن حجم به ترتیب در حالت فقط‌خواندنی یا خواندنی-نوشتنی اضافه کنید. به طور پیش‌فرض، حجم‌ها به صورت خواندنی-نوشتنی سوار می‌شوند. به مثال‌ها مراجعه کنید.

.PP
\fBتغییر مالکیت (Chowning) مانت‌های حجم\fR

.PP
هنگامی که یک حجم نام‌گذاری‌شده برای نخستین بار به یک کانتینر سوار می‌شود، پادمن به صورت خودکار مالکیت نقطه مانت حجم را در حین مقداردهی اولیه کانتینر تنظیم می‌کند. این عملیات chown تحت شرایط زیر رخ می‌دهد:
.IP \(bu 2
حجم هنوز استفاده نشده باشد (دارای \fBNeedsChown\fR تنظیم‌شده روی true باشد)
.IP \(bu 2
حجم خالی باشد یا هنوز کپی نشده باشد (copied up)
.IP \(bu 2
حجم توسط یک درایور حجم خارجی مدیریت نشود
.IP \(bu 2
درایور حجم "image" نباشد

.PP
برای حجم‌های دارای مانت idmapped (با استفاده از گزینه \fBidmap\fR)، تغییر مالکیت نگاشت‌های فضای نام کاربری کانتینر را لحاظ می‌کند، اما حجم idmapped نگاشت مناسب UID/GID را حفظ می‌نماید. برای حجم‌های بدون idmapping، نقطه مانت به مالکیت کاربر و گروه فرایند کانتینر تغییر می‌یابد که در صورت فعال بودن نگاشت مجدد فضای نام کاربری، به فضای نام کاربری میزبان نگاشت می‌شود.

.PP
اگر کانتینری در یک فضای نام کاربری جدید ایجاد شود، UID و GID درون کانتینر ممکن است متناظر با UID و GID دیگری روی میزبان باشد.

.PP
پسوند \fB:U\fR به پادمن می‌گوید از UID و GID صحیح میزبان بر اساس UID و GID درون کانتینر استفاده کند تا مالک و گروه حجم مبدا را به صورت بازگشتی تغییر دهد. عملیات Chown در سیستم‌فایل زیر حجم پیمایش کرده و UID/GID را روی هر فایل تغییر می‌دهد. اگر حجم دارای هزاران inode باشد، این فرایند زمان زیادی برده و شروع کانتینر را به تاخیر می‌اندازد.

.PP
\fBهشدار:\fP با احتیاط استفاده شود چرا که این گزینه سیستم‌فایل میزبان را تغییر می‌دهد.

.PP
\fBبرچسب‌گذاری مانت‌های حجم\fR

.PP
سیستم‌های برچسب‌گذاری مانند SELinux نیاز دارند که برچسب‌های مناسب روی محتوای حجمِ مانت‌شده در کانتینر قرار گیرند. بدون برچسب، سیستم امنیتی ممکن است از استفاده محتوا توسط فرایندهای در حال اجرا درون کانتینر جلوگیری کند. به طور پیش‌فرض، پادمن برچسب‌های تنظیم‌شده توسط سیستم‌عامل را تغییر نمی‌دهد.

.PP
برای تغییر برچسب در بستر کانتینر، یکی از دو پسوند \fB:z\fP یا \fB:Z\fP را به مانت حجم اضافه کنید. این پسوندها به پادمن می‌گویند اشیاء فایلی را روی حجم‌های مشترک بازبرچسب‌گذاری (relabel) کند. گزینه \fBz\fP به پادمن می‌گوید دو یا چند کانتینر محتوای حجم را به اشتراک می‌گذارند. در نتیجه، پادمن محتوا را با یک برچسب محتوای مشترک علامت‌گذاری می‌کند. برچسب‌های حجم مشترک به همه کانتینرها اجازه خواندن/نوشتن محتوا را می‌دهند. گزینه \fBZ\fP به پادمن می‌گوید محتوا را با یک برچسب خصوصی و غیرمشترک علامت‌گذاری کند. تنها کانتینر جاری می‌تواند از حجم خصوصی استفاده کند.

.PP
نکته: همه کانتینرهای درون یک \fBپاد (pod)\fR دارای برچسب SELinux یکسانی هستند. این بدان معناست که همه کانتینرهای درون پاد مذکور می‌توانند حجم‌های مشترک‌شده در کانتینر ایجادشده با \fB:Z\fR را روی هر یک از کانتینرها بخوانند/بنویسند. بازبرچسب‌گذاری در سیستم‌فایل زیر حجم پیمایش کرده و برچسب هر فایل را تغییر می‌دهد؛ اگر حجم دارای هزاران inode باشد، این فرایند زمان زیادی می‌برد و شروع کانتینر را به تاخیر می‌اندازد. اگر حجم قبلاً با گزینه \fBz\fR بازبرچسب‌گذاری شده باشد، پادمن بهینه‌سازی شده تا بار دوم آن را بازبرچسب‌گذاری نکند. اگر فایل‌ها به درون حجم منتقل شوند، برچسب‌ها را می‌توان به صورت دستی با دستور \fBchcon -Rt container_file_t PATH\fR تغییر داد.

.PP
نکته: فایل‌ها و دایرکتوری‌های سیستم را بازبرچسب‌گذاری نکنید. بازبرچسب‌گذاری محتوای سیستم ممکن است باعث از کار افتادن سایر سرویس‌های محدودشده روی ماشین شود. برای این نوع کانتینرها توصیه می‌کنیم جداسازی SELinux را غیرفعال کنید. گزینه \fB--security-opt label=disable\fP جداسازی SELinux را برای کانتینر غیرفعال می‌کند. برای نمونه اگر کاربری بخواهد کل دایرکتوری خانگی (home) خود را در کانتینر سوار کند، باید جداسازی SELinux را غیرفعال سازد.

.EX
$ podman run --security-opt label=disable -v $HOME:/home/user fedora touch /home/user/file
.EE

.PP
\fBمانت‌های حجم Overlay\fR

.PP
فلگ \fB:O\fR به پادمن می‌گوید دایرکتوری حاصل از میزبان را به عنوان یک فضای ذخیره‌سازی موقت با استفاده از \fBسیستم‌فایل overlay\fR سوار کند. فرایندهای کانتینر می‌توانند محتوای درون نقطه مانت را تغییر دهند که در فضای ذخیره‌سازی کانتینر در یک دایرکتوری جداگانه ذخیره می‌شود. در اصطلاحات overlay، دایرکتوری مبدا lower است و دایرکتوری ذخیره‌سازی کانتینر upper می‌باشد. تغییرات نقطه مانت پس از اتمام اجرای کانتینر از بین می‌روند، مشابه حالتی که یک نقطه مانت tmpfs از حالت مانت خارج شود.

.PP
برای کاربران پیشرفته، گزینه \fBoverlay\fP همچنین از \fBupperdir\fP و \fBworkdir\fP سفارشی غیرفرار برای مانت overlay پشتیبانی می‌کند. دایرکتوری‌های سفارشی \fBupperdir\fP و \fBworkdir\fP می‌توانند کاملاً توسط خود کاربران مدیریت شوند و پادمن در پایان چرخه حیات آن‌ها را حذف نمی‌کند.
مثال: \fB:O,upperdir=/some/upper,workdir=/some/work\fP

.PP
اجراهای بعدی کانتینر محتوای دایرکتوری مبدا اصلی را مشاهده می‌کنند و هرگونه تغییرات از اجراهای قبلی کانتینر دیگر وجود نخواهد داشت.

.PP
یکی از موارد استفاده مانت overlay به اشتراک‌گذاری کش بسته‌ها از میزبان به درون کانتینر برای افزایش سرعت ساخت است.

.PP
نکته: فلگ \fBO\fR با سایر گزینه‌های ذکرشده در بالا تداخل دارد.

.PP
محتوای مانت‌شده درون کانتینر با برچسب خصوصی برچسب‌گذاری می‌شود. در سیستم‌های SELinux، برچسب‌ها در دایرکتوری مبدا باید توسط برچسب کانتینر خواندنی باشند. معمولاً کانتینرها می‌توانند \fBcontainer_share_t\fR را بخوانند/اجرا کنند و می‌توانند روی \fBcontainer_file_t\fR بخوانند/بنویسند. در صورت عدم امکان تغییر برچسب‌ها روی حجم مبدا، برای کارکرد کانتینر باید جداسازی کانتینر در SELinux غیرفعال شود.

.PP
دایرکتوری مبدا مانت‌شده درون کانتینر با مانت overlay را تغییر ندهید، چرا که ممکن است باعث خطاهای غیرمنتظره شود. دایرکتوری را تنها پس از پایان اجرای کانتینر تغییر دهید.

.PP
\fBانتشار مانت‌ها (Mounts propagation)\fR

.PP
به طور پیش‌فرض، حجم‌های bind-mount به صورت \fBprivate\fR هستند. این بدان معنی است که هر مانت انجام‌شده درون کانتینر روی میزبان قابل مشاهده نیست و برعکس.
می‌توان این رفتار را با مشخص کردن یک ویژگی انتشار مانت تغییر داد. هنگامی که یک حجم \fBshared\fR باشد، مانت‌های انجام‌شده در زیر آن حجم درون کانتینر روی میزبان قابل مشاهده هستند و برعکس. قرار دادن یک حجم در حالت \fBslave\fP[1]
\[la]#Footnote1\[ra]
تنها انتشار مانت یک‌طرفه را فعال می‌کند: مانت‌های انجام‌شده روی میزبان در زیر آن حجم درون کانتینر قابل مشاهده هستند اما برعکس آن صادق نیست.

.PP
برای کنترل ویژگی انتشار مانت یک حجم، می‌توان از فلگ انتشار [\fBr\fP]\fBshared\fP، [\fBr\fP]\fBslave\fP، [\fBr\fP]\fBprivate\fP یا [\fBr\fP]\fBunbindable\fP استفاده کرد. ویژگی انتشار تنها برای حجم‌های بایند مانت قابل تعیین است و نه برای حجم‌های داخلی یا حجم‌های نام‌گذاری‌شده. برای کارکرد انتشار مانت، نقطه مانت مبدا (نقطه مانتی که دایرکتوری مبدا روی آن مانت شده است) باید ویژگی‌های انتشار مناسب را داشته باشد. برای حجم‌های مشترک، نقطه مانت مبدا باید shared باشد. و برای حجم‌های slave، نقطه مانت مبدا باید shared یا slave باشد.
[1]
\[la]#Footnote1\[ra]

.PP
برای سوار کردن بازگشتی یک حجم و تمام زیرمانت‌های آن درون یک کانتینر، از گزینه \fBrbind\fP استفاده کنید. به طور پیش‌فرض گزینه bind استفاده می‌شود و زیرمانت‌های دایرکتوری مبدا درون کانتینر سوار نمی‌شوند.

.PP
سوار کردن حجم با گزینه \fBcopy\fP به پادمن می‌گوید محتوا را از دایرکتوری مقصد زیرین روی حجم‌های داخلی تازه ایجادشده کپی کند. عمل \fBcopy\fP تنها در زمان ایجاد اولیه حجم انجام می‌شود. محتوا هنگام استفاده بعدی از حجم در کانتینرهای مختلف کپی نمی‌شود. گزینه \fBcopy\fP در مانت‌های بایند نادیده گرفته شده و تاثیری ندارد.

.PP
سوار کردن حجم‌ها با گزینه‌های \fBnosuid\fP بدان معنی است که فایل‌های اجرایی SUID روی حجم نمی‌توانند توسط برنامه‌ها برای تغییر امتیاز خود استفاده شوند. به طور پیش‌فرض حجم‌ها با \fBnosuid\fP سوار می‌شوند.

.PP
سوار کردن حجم با گزینه \fBnoexec\fP بدان معنی است که هیچ فایل اجرایی روی حجم درون کانتینر قابل اجرا نیست.

.PP
سوار کردن حجم با گزینه \fBnodev\fP بدان معنی است که هیچ دستگاهی روی حجم نمی‌تواند توسط فرایندهای درون کانتینر استفاده شود. به طور پیش‌فرض حجم‌ها با \fBnodev\fP سوار می‌شوند.

.PP
اگر \fIHOST-DIR\fP یک نقطه مانت باشد، گزینه‌های \fBdev\fP، \fBsuid\fP و \fBexec\fP توسط هسته نادیده گرفته می‌شوند.

.PP
از دستور \fBdf HOST-DIR\fP برای یافتن مانت مبدا استفاده کنید، سپس از
\fBfindmnt -o TARGET,PROPAGATION \fIsource-mount-dir\fP\fP برای یافتن ویژگی‌های انتشار مانت مبدا بهره ببرید. اگر ابزار \fBfindmnt\fP(1) در دسترس نیست، می‌توانید ورودی مانت را برای نقطه مانت مبدا در \fI/proc/self/mountinfo\fP بررسی کنید. به "فیلدهای اختیاری" نگاه کنید تا ببینید آیا هیچ ویژگی انتشاری مشخص شده است یا خیر. در آنجا، \fBshared:N\fP به معنی اشتراکی بودن مانت است، \fBmaster:N\fP به معنی حالت slave است، و اگر چیزی نبود، مانت خصوصی است. [1]
\[la]#Footnote1\[ra]

.PP
برای تغییر ویژگی‌های انتشار یک نقطه مانت، از دستور \fBmount\fP(8) استفاده کنید. برای نمونه، اگر می‌خواهید دایرکتوری مبدا \fI/foo\fP را به صورت bind سوار کنید، می‌توانید دستورهای
\fBmount --bind /foo /foo\fP و \fBmount --make-private --make-shared /foo\fP را اجرا کنید. این کار /foo را به یک نقطه مانت مشترک تبدیل می‌کند. از سوی دیگر، می‌توانید مستقیماً ویژگی‌های انتشار مانت مبدا را تغییر دهید. فرض کنید \fI/\fP مانت مبدا برای \fI/foo\fP باشد، در این صورت از \fBmount --make-shared /\fP برای تبدیل \fI/\fP به یک مانت مشترک استفاده کنید.

.PP
نکته: اگر کاربر تنها از طریق یک گروه حقوق دسترسی داشته باشد، دسترسی به حجم از داخل یک کانتینر بدون ریشه با شکست مواجه می‌شود.

.PP
\fBمانت Idmapped\fR

.PP
اگر \fBidmap\fR مشخص شود، یک مانت idmapped به فضای نام کاربری هدف در کانتینر ایجاد می‌کند. گزینه idmap از یک نگاشت سفارشی پشتیبانی می‌کند که می‌تواند متفاوت از فضای نام کاربری مورد استفاده توسط کانتینر باشد. نگاشت را می‌توان پس از گزینه idmap به این صورت مشخص کرد:
\fBidmap=uids=0-1-10#10-11-10;gids=0-100-10\fR\&.
برای هر سه‌تایی، مقدار اول شروع شناسه‌های سیستم‌فایل پشتیبان است که به مقدار دوم روی میزبان نگاشت می‌شوند. طول این نگاشت در مقدار سوم ارائه می‌شود.
بازه‌های متعدد با علامت # از یکدیگر جدا می‌شوند.

.PP
از گزینه \fB--group-add keep-groups\fP برای انتقال دسترسی گروه تکمیلی کاربر به درون کانتینر استفاده کنید.

.SS \fB--volumes-from\fP=\fICONTAINER[:OPTIONS]\fP
سوار کردن حجم‌ها از کانتینر(های) مشخص‌شده. برای به اشتراک‌گذاری حجم‌ها بین کانتینرها استفاده می‌شود. مقدار \fIoptions\fP لیستی جداشده با کاما با عناصر در دسترس زیر است:
.IP \(bu 2
\fBrw\fP|\fBro\fP
.IP \(bu 2
\fBz\fP

.PP
حجم‌های از قبل سوارشده از یک کانتینر مبدا را روی کانتینر دیگر سوار می‌کند. مقدار \fICONTAINER\fP می‌تواند نام یا شناسه باشد. برای اشتراک‌گذاری یک حجم، از گزینه --volumes-from هنگام اجرای کانتینر مقصد استفاده کنید. حجم‌ها را حتی در صورتی که کانتینر مبدا در حال اجرا نباشد می‌توان به اشتراک گذاشت.

.PP
به طور پیش‌فرض، پادمن حجم‌ها را در همان حالتی (خواندنی-نوشتنی یا فقط‌خواندنی) که در کانتینر مبدا سوار شده است سوار می‌کند. این را می‌توان با افزودن گزینه \fBro\fR یا \fBrw\fR تغییر داد.

.PP
سیستم‌های برچسب‌گذاری مانند SELinux نیازمند آن هستند که برچسب‌های مناسب روی محتوای حجم مانت‌شده درون کانتینر قرار گیرند. بدون برچسب، سیستم امنیتی ممکن است مانع از استفاده فرایندهای در حال اجرا در کانتینر از محتوا شود. به طور پیش‌فرض، پادمن برچسب‌های تنظیم‌شده توسط سیستم‌عامل را تغییر نمی‌دهد.

.PP
برای تغییر یک برچسب در بستر کانتینر، پسوند \fBz\fR را به مانت حجم اضافه کنید. این پسوند به پادمن می‌گوید اشیاء فایلی را روی حجم‌های مشترک بازبرچسب‌گذاری کند. گزینه \fBz\fR به پادمن می‌گوید دو نهاد محتوای حجم را به اشتراک می‌گذارند. در نتیجه، پادمن محتوا را با یک برچسب محتوای مشترک برچسب‌گذاری می‌کند. برچسب‌های حجم مشترک به همه کانتینرها اجازه خواندن/نوشتن محتوا را می‌دهند.

.PP
اگر مکان حجم حاصل از کانتینر مبدا با داده‌های مقیم روی کانتینر مقصد هم‌پوشانی داشته باشد، در این صورت حجم آن داده‌ها را روی مقصد پنهان می‌کند.

.SS \fB--workdir\fP, \fB-w\fP=\fIdir\fP
دایرکتوری کاری درون کانتینر.

.PP
دایرکتوری کاری پیش‌فرض برای اجرای فایل‌های اجرایی درون کانتینر، دایرکتوری ریشه (\fB/\fP) است. توسعه‌دهنده ایمیج می‌تواند با دستورالعمل WORKDIR پیش‌فرض متفاوتی را تنظیم کند. مجری کانتینر می‌تواند دایرکتوری کاری را با استفاده از گزینه \fB-w\fP بازنویسی کند.

.SH "وضعیت خروج (EXIT STATUS)"
کد خروج از \fBpodman run\fP اطلاعاتی را در مورد چرایی عدم موفقیت کانتینر
در اجرا یا دلیل خروج آن ارائه می‌دهد. هنگامی که \fBpodman run\fP با کدی غیر از صفر خارج می‌شود،
کدهای خروج از استاندارد \fBchroot\fP(1) پیروی می‌کنند، به شرح زیر:

.PP
\fB125\fP خطا از خود پادمن است

.EX
$ podman run --foo busybox; echo $?
Error: unknown flag: --foo
125
.EE

.PP
\fB126\fP \fIدستور درون کانتینر\fP قابل فراخوانی نیست

.EX
$ podman run busybox /etc; echo $?
Error: container_linux.go:346: starting container process caused "exec: \"/etc\": permission denied": OCI runtime error
126
.EE

.PP
\fB127\fP \fIدستور درون کانتینر\fP یافت نمی‌شود

.EX
$ podman run busybox foo; echo $?
Error: container_linux.go:346: starting container process caused "exec: \"foo\": executable file not found in $PATH": OCI runtime error
127
.EE

.PP
\fBکد خروج\fP کد خروج \fIدستور درون کانتینر\fP

.EX
$ podman run busybox /bin/sh -c 'exit 3'; echo $?
3
.EE

.SH "مثال‌ها (EXAMPLES)"
.SS اجرای کانتینر در حالت فقط‌خواندنی
در طول توسعه ایمیج کانتینر، کانتینرها اغلب نیاز دارند در محتوای ایمیج بنویسند؛
برای مثال نصب بسته‌ها در \fI/usr\fP. در محیط عملیاتی، برنامه‌ها به ندرت نیاز به نوشتن
در ایمیج دارند. برنامه‌های کانتینری در صورت نیاز به نوشتن در سیستم‌فایل، در حجم‌ها
(volumes) می‌نویسند. با اجرای برنامه‌ها در حالت فقط‌خواندنی با استفاده از سوئیچ \fB--read-only\fP،
می‌توان امنیت آن‌ها را ارتقا داد. این کار ایمیج کانتینر را در برابر تغییر محافظت می‌کند.
به طور پیش‌فرض کانتینرهای فقط‌خواندنی می‌توانند روی داده‌های موقت بنویسند. پادمن یک tmpfs
را روی \fI/run\fP و \fI/tmp\fP در داخل کانتینر مانت می‌کند.

.EX
$ podman run --read-only -i -t fedora /bin/bash
.EE

.PP
اگر کانتینر به هیچ سیستم‌فایلی درون کانتینر، از جمله tmpfs، نمی‌نویسد، مقدار --read-only-tmpfs=false را تنظیم کنید.

.EX
$ podman run --read-only --read-only-tmpfs=false --tmpfs /run -i -t fedora /bin/bash
.EE

.SS ارائه کتابخانه‌های اشتراکی درون کانتینر به صورت فقط‌خواندنی با استفاده از glob
.EX
$ podman run --mount type=glob,src=/usr/lib64/libnvidia\*,ro=true -i -t fedora /bin/bash
.EE

.SS ارسال پیام‌های لاگ از کانتینر به سیستم لاگ میزبان
دایرکتوری \fI/dev/log\fP را bind mount کنید تا پیام‌هایی که در کانتینر ثبت می‌شوند
در syslog/journal میزبان نمایش داده شوند.

.EX
$ podman run -v /dev/log:/dev/log -i -t fedora /bin/bash
.EE

.PP
از داخل کانتینر با ارسال یک پیام به لاگر این موضوع را آزمایش کنید:

.EX
(bash)# logger "Hello from my container"
.EE

.PP
سپس خارج شده و journal را بررسی کنید:

.EX
(bash)# exit

$ journalctl -b | grep Hello
.EE

.PP
این دستور پیامی را که به لاگر ارسال شده فهرست می‌کند.

.SS اتصال به یک یا چند مورد از STDIN، STDOUT، STDERR
بدون مشخص کردن گزینه \fB-a\fP، پادمن همه موارد (stdin, stdout, stderr) را متصل می‌کند.
با مشخص کردن a- (stdin, stdout, stderr) مقدار پیش‌فرض را بازنویسی کنید، مانند:

.EX
$ podman run -a stdin -a stdout -i -t fedora /bin/bash
.EE

.SS اشتراک‌گذاری IPC بین کانتینرها
با استفاده از \fBshm_server.c\fP موجود در: https://www.cs.cf.ac.uk/Dave/C/node27.html

.PP
آزمایش حالت \fB--ipc=host\fP:

.PP
میزبان یک بخش حافظه اشتراکی با ۷ pid متصل نشان می‌دهد که متعلق به httpd است:

.EX
$ sudo ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x01128e25 0          root       600        1000       7
.EE

.PP
اکنون یک کانتینر معمولی را اجرا کنید؛ این کانتینر به درستی بخش حافظه اشتراکی از میزبان را نمی‌بیند:

.EX
$ podman run -it shm ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
.EE

.PP
یک کانتینر با گزینه جدید \fB--ipc=host\fP اجرا کنید؛ اکنون بخش حافظه اشتراکی از httpd میزبان را می‌بیند:

.EX
$ podman run -it --ipc=host shm ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x01128e25 0          root       600        1000       7
.EE

.PP
آزمایش حالت \fB--ipc=container:\fP\fIid\fP:

.PP
یک کانتینر را با برنامه‌ای برای ایجاد بخش حافظه اشتراکی شروع کنید:

.EX
$ podman run -it shm bash
$ sudo shm/shm_server &
$ sudo ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x0000162e 0          root       666        27         1
.EE

.PP
ایجاد کانتینر دوم به درستی هیچ بخش حافظه اشتراکی از کانتینر اول را نشان نمی‌دهد:

.EX
$ podman run shm ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
.EE

.PP
ایجاد کانتینر سوم با استفاده از گزینه \fB--ipc=container:\fP\fIid\fP؛ اکنون بخش حافظه اشتراکی از کانتینر اول را نشان می‌دهد:

.EX
$ podman run -it --ipc=container:ed735b2264ac shm ipcs -m
$ sudo ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x0000162e 0          root       666        27         1
.EE

.SS نگاشت پورت‌ها برای استفاده خارجی
پورت ارائه شده یک برنامه را می‌توان با استفاده از پرچم \fB-p\fP به یک پورت میزبان نگاشت کرد.
برای مثال، پورت 80 در httpd را می‌توان با دستور زیر به پورت 8080 میزبان نگاشت نمود:

.EX
$ podman run -p 8080:80 -d fedora/httpd
.EE

.SS اتصال حجم‌های خارجی (Mounting External Volumes)
برای مانت کردن یک مسیر دایرکتوری میزبان به عنوان حجم کانتینر، مسیر مطلق
دایرکتوری و مسیر مطلق دایرکتوری کانتینر را که با دونقطه جدا شده‌اند مشخص کنید. اگر منبع یک حجم نام‌گذاری‌شده
تحت مدیریت پادمن است، توصیه می‌شود به‌جای مسیر حجم از نام آن استفاده شود. در غیر این صورت حجم به عنوان یک حجم یتیم (orphan)
در نظر گرفته شده و با دستور \fBpodman volume prune\fP پاک خواهد شد:

.EX
$ podman run -v /var/db:/data1 -i -t fedora bash

$ podman run -v data:/data2 -i -t fedora bash

$ podman run -v /var/cache/dnf:/var/cache/dnf:O -ti fedora dnf -y update
.EE

.PP
اگر کانتینر به یک حجم مانت‌شده با قابلیت نوشتن توسط کاربری غیر از root درون کانتینر نیاز دارد، از گزینه \fBU\fP استفاده کنید. این گزینه به پادمن دستور می‌دهد تا مالکیت (chown) حجم منبع را مطابق با UID و GID پیش‌فرض استفاده‌شده درون کانتینر تنظیم کند.

.EX
$ podman run -d -e MARIADB_ROOT_PASSWORD=root --user mysql --userns=keep-id -v ~/data:/var/lib/mysql:Z,U mariadb
.EE

.PP
همچنین اگر کانتینر به حجم قابل نوشتن توسط یک کاربر غیر root درون کانتینر نیاز دارد، گزینه --userns=keep-id به کاربران اجازه می‌دهد
UID و GID کاربری را که پادمن را اجرا می‌کند به UIDها و GIDهای مشخصی در داخل کانتینر نگاشت کنند. از آنجا که فرایندهای در حال اجرا
در کانتینر با UID کاربر اجرا می‌شوند، می‌توانند فایل‌های متعلق به کاربر را بخوانند/بنویسند.

.EX
$ podman run -d -e MARIADB_ROOT_PASSWORD=root --user mysql --userns=keep-id:uid=999,gid=999 -v ~/data:/var/lib/mysql:Z mariadb
.EE

.PP
با استفاده از پرچم‌های \fB--mount\fP برای مانت کردن یک دایرکتوری میزبان به عنوان پوشه کانتینر، مسیر مطلق
دایرکتوری یا نام حجم و مسیر مطلق درون دایرکتوری کانتینر را مشخص کنید:

.EX
$ podman run --mount type=bind,src=/var/db,target=/data1 busybox sh

$ podman run --mount type=bind,src=volume-name,target=/data1 busybox sh
.EE

.PP
پرچم \fB--mount\fP یک ساختار کلید-مقدار برای تعریف مانت‌ها در داخل کانتینرها فراهم می‌کند. این گزینه
از نظر کاربرد مشابه \fB-v\fP یا \fB--volume\fP است، اما برای پیکربندی‌های پیچیده یا دارای گزینه‌های متعدد
وضوح بیشتری ارائه می‌دهد. سینتکس کلی به این صورت است:

.EX
--mount type=<TYPE>,src=<SOURCE>,dst=<TARGET>[,options...]
.EE

.PP
انواع مانت پشتیبانی‌شده شامل \fBbind\fP، \fBvolume\fP، \fBtmpfs\fP، \fBartifact\fP،
\fBdevpts\fP، \fBimage\fP، \fBglob\fP و \fBramfs\fP است. هر نوع در نحوه اتصال داده‌ها به کانتینر
هدف متفاوتی را دنبال می‌کند.

.SS مانت‌های نوع Bind
مانت‌های Bind به طور مستقیم یک دایرکتوری یا فایل را روی میزبان به کانتینر متصل می‌کنند.
تغییرات اعمال‌شده در هر یک بلافاصله در دیگری قابل مشاهده است. زمانی از bind mount استفاده کنید که
هم میزبان و هم کانتینر نیاز به دسترسی به فایل‌های یکسانی دارند، مانند فایل‌های پیکربندی یا کدهای منبع.

.PP
مثال:

.EX
podman run --mount type=bind,src=/etc/config,dst=/app/config alpine cat /app/config/file.conf
.EE

.SS مانت‌های نوع Volume
مانت‌های Volume از حجم‌های نام‌گذاری‌شده و مدیریت‌شده توسط پادمن استفاده می‌کنند که مستقل از کانتینرها
پایدار باقی می‌مانند. آن‌ها برای داده‌های ماندگار مانند پایگاه‌های داده یا فایل‌های گزارش ایده‌آل هستند
و از مسیرهای مستقیم میزبان ایزوله شده‌اند.

.PP
مثال:

.EX
podman volume create mydata
podman run --mount type=volume,src=mydata,dst=/var/lib/data postgres
.EE

.SS مانت‌های نوع Tmpfs
یک مانت tmpfs یک سیستم‌فایل مبتنی بر حافظه موقت (RAM) روی میزبان ایجاد می‌کند که درون کانتینر مانت می‌شود.
داده‌های ذخیره‌شده در اینجا موقتی هستند و با توقف کانتینر یا راه‌اندازی مجدد میزبان حذف می‌شوند.
مانت‌های tmpfs برای کش‌های موقت یا داده‌های حساسی که نباید روی دیسک ذخیره شوند مفید هستند.

.PP
مثال:

.EX
podman run --mount type=tmpfs,dst=/cache,tmpfs-size=64m alpine
.EE

.SS مانت‌های نوع Artifact، devpts، image، glob و ramfs
سایر انواع مانت‌های تخصصی برای موارد استفاده پیشرفته در دسترس هستند:
.IP \(bu 2
\fBartifact\fP - محتوای فقط‌خواندنی را از یک ایمیج یا آرتیفکت کانتینر مانت می‌کند.
.IP \(bu 2
\fBdevpts\fP - یک دستگاه شبه‌ترمینال (pseudo-terminal) درون کانتینر ارائه می‌دهد.
.IP \(bu 2
\fBimage\fP - فایل‌ها را مستقیماً از یک ایمیج کانتینر دیگر مانت می‌کند.
.IP \(bu 2
\fBglob\fP - چندین فایل میزبان منطبق بر یک الگوی glob را مانت می‌کند.
.IP \(bu 2
\fBramfs\fP - مشابه tmpfs است اما مستقیماً بر پایه‌ی RAM سیستم و بدون محدودیت اندازه کار می‌کند.

.PP
این نوع مانت‌ها کمتر مورد استفاده قرار می‌گیرند و اغلب در جریان‌های کاری داخلی یا پیشرفته پادمن دیده می‌شوند.

.PP
به طور خلاصه، \fB--mount\fP یک رابط منسجم برای اتصال فضاهای ذخیره‌سازی خارجی به کانتینرها فراهم می‌کند.
نوع مانتی را انتخاب کنید که به بهترین شکل با نیاز شما سازگار است: \fBbind\fP برای دسترسی مستقیم میزبان،
\fBvolume\fP برای داده‌های ماندگار مدیریت‌شده توسط پادمن، و \fBtmpfs\fP برای ذخیره‌سازی موقت در حافظه.

.PP
هنگام استفاده از SELinux، توجه داشته باشید که میزبان اطلاعی از سیاست‌های SELinux کانتینر ندارد.
بنابراین، در مثال بالا، در صورت اعمال سیاست SELinux، دایرکتوری \fI/var/db\fP برای کانتینر قابل نوشتن نخواهد بود.
یک پیام "Permission Denied" رخ می‌دهد و پیام \fBavc:\fP به syslog میزبان اضافه می‌شود.

.PP
برای حل این مشکل، در زمان نگارش این صفحه راهنما، دستور زیر باید اجرا شود تا برچسب نوع سیاست SELinux مناسب
به دایرکتوری میزبان متصل گردد:

.EX
$ chcon -Rt svirt_sandbox_file_t /var/db
.EE

.PP
اکنون نوشتن روی حجم \fI/data1\fP درون کانتینر مجاز است و تغییرات در \fI/var/db\fP روی میزبان منعکس می‌شود.

.SS استفاده از برچسب‌گذاری امنیتی جایگزین
طرح برچسب‌گذاری پیش‌فرض برای هر کانتینر را با مشخص کردن پرچم \fB--security-opt\fP بازنویسی کنید.
برای نمونه، سطح MCS/MLS را مشخص کنید که الزامی برای سیستم‌های MLS است. مشخص کردن سطح در دستور زیر
اجازه می‌دهد تا محتوای یکسان بین کانتینرها به اشتراک گذاشته شود.

.EX
podman run --security-opt label=level:s0:c100,c200 -i -t fedora bash
.EE

.PP
یک مثال برای MLS می‌تواند چنین باشد:

.EX
$ podman run --security-opt label=level:TopSecret -i -t rhel7 bash
.EE

.PP
برای غیرفعال کردن برچسب‌گذاری امنیتی برای این کانتینر در مقایسه با اجرا همراه با پرچم \fB--permissive\fP، از دستور زیر استفاده کنید:

.EX
$ podman run --security-opt label=disable -i -t fedora bash
.EE

.PP
سیاست امنیتی را روی فرایندهای درون کانتینر با مشخص کردن یک نوع جایگزین برای کانتینر تشدید کنید.
برای نمونه، اجرای کانتینری که تنها مجاز به شنود روی پورت‌های آپاچی است با اجرای دستور زیر ممکن می‌شود:

.EX
$ podman run --security-opt label=type:svirt_apache_t -i -t centos bash
.EE

.PP
توجه داشته باشید که باید سیاست SELinux تعریف‌کننده نوع \fBsvirt_apache_t\fP نوشته شده باشد.

.PP
برای ماسک کردن مسیرهای خاص اضافی در کانتینر، مسیرها را با دونقطه جدا کرده و با استفاده از گزینه
\fBmask\fP همراه با پرچم \fB--security-opt\fP مشخص کنید.

.EX
$ podman run --security-opt mask=/foo/bar:/second/path fedora bash
.EE

.PP
برای رفع ماسک (unmask) از تمامی مسیرهایی که به طور پیش‌فرض ماسک شده‌اند، گزینه \fBunmask\fP را روی
\fBALL\fP تنظیم کنید. یا برای رفع ماسک تنها از مسیرهای خاص، مسیرها را همان‌طور که در بالا با گزینه
\fBmask\fP نشان داده شد تعیین نمایید.

.EX
$ podman run --security-opt unmask=ALL fedora bash
.EE

.PP
برای رفع ماسک از تمام مسیرهایی که با proc/ شروع می‌شوند، گزینه \fBunmask\fP را روی \fB/proc/\fP* تنظیم کنید.

.EX
$ podman run --security-opt unmask=/proc/* fedora bash
.EE

.EX
$ podman run --security-opt unmask=/foo/bar:/sys/firmware fedora bash
.EE

.SS تنظیم وزن دستگاه با پرچم \fB--blkio-weight-device\fP
.EX
$ podman run -it --blkio-weight-device "/dev/sda:200" ubuntu
.EE

.SS استفاده از کانتینر پادمن با ورودی از پایپ (pipe)
.EX
$ echo "asdf" | podman run --rm -i --entrypoint /bin/cat someimage
asdf
.EE

.SS تنظیم کانتینرهای تفکیک‌شده با فضای نام کاربری خودکار
.EX
# podman run --userns=auto:size=65536 ubi8-micro cat /proc/self/uid_map
0 2147483647      65536
# podman run --userns=auto:size=65536 ubi8-micro cat /proc/self/uid_map
0 2147549183      65536
.EE

.SS تنظیم پارامترهای کرنل دارای فضای نام (Sysctls)
گزینه \fB--sysctl\fP پارامترهای کرنل دارای فضای نام (sysctlها) را در
کانتینر تنظیم می‌کند. برای مثال، برای فعال‌سازی فورواردینگ IP در فضای نام شبکه
کانتینرها، این دستور را اجرا کنید:

.EX
$ podman run --sysctl net.ipv4.ip_forward=1 someimage
.EE

.PP
توجه داشته باشید که همه sysctlها دارای فضای نام نیستند. پادمن از تغییر دادن sysctlهایی در داخل
کانتینر که سیستم میزبان را نیز تغییر دهند پشتیبانی نمی‌کند. با تکامل کرنل،
انتظار می‌رود sysctlهای بیشتری دارای فضای نام شوند.

.PP
تعریف گزینه \fB--sysctl\fP در بالا را برای فهرست فعلی sysctlهای پشتیبانی‌شده ببینید.

.SS تنظیم نگاشت UID/GID در یک فضای نام کاربری جدید
اجرای کانتینر در یک فضای نام کاربری جدید نیازمند نگاشت UIDها و GIDها از سیستم میزبان است.

.EX
$ podman run --uidmap 0:30000:7000 --gidmap 0:30000:7000 fedora echo hello
.EE

.SS پیکربندی گزینه‌های ذخیره‌سازی از خط فرمان
پادمن امکان پیکربندی ذخیره‌سازی را با تغییر مقادیر در \fI/etc/container/storage.conf\fP
یا با استفاده از گزینه‌های سراسری فراهم می‌کند. این مثال نشان می‌دهد که چگونه می‌توان از یک
فضای ذخیره‌سازی ایمیج اضافی برای یک بار اجرای busybox با استفاده از گزینه‌های سراسری بهره برد.

.EX
podman --log-level=debug --storage-opt "additionalimagestore=/tmp/readonly-images" run busybox /bin/sh
.EE

.SS پیکربندی منطقه زمانی در کانتینر
.EX
$ podman run --tz=local alpine date
$ podman run --tz=Asia/Shanghai alpine date
$ podman run --tz=US/Eastern alpine date
.EE

.SS افزودن کانتینرهای وابسته
کانتینر اول، container1، در ابتدا شروع نمی‌شود، اما قبل از شروع container2 باید در حال اجرا باشد.
دستور \fBpodman run\fR پیش از راه‌اندازی container2، کانتینر وابسته را به صورت خودکار شروع می‌کند.

.EX
$ podman create --name container1 -t -i fedora bash
$ podman run --name container2 --requires container1 -t -i fedora bash
.EE

.PP
می‌توان چندین کانتینر را الزامی کرد.

.EX
$ podman create --name container1 -t -i fedora bash
$ podman create --name container2 -t -i fedora bash
$ podman run --name container3 --requires container1,container2 -t -i fedora bash
.EE

.SS پیکربندی حفظ گروه‌های تکمیلی برای دسترسی به حجم
.EX
$ podman run -v /var/lib/design:/var/lib/design --group-add keep-groups ubi8
.EE

.SS پیکربندی دامنه اجرا برای کانتینرها با پرچم personality
.EX
$ podman run --name container1 --personality=LINUX32 fedora bash
.EE

.SS اجرای کانتینر با rootfs خارجی مانت‌شده به صورت overlay
.EX
$ podman run --name container1 --rootfs /path/to/rootfs:O bash
.EE

.SS مدیریت مناطق زمانی در برنامه‌های جاوا درون کانتینر
برای استفاده از منطقه‌ای زمانی به جز UTC هنگام اجرای یک برنامه جاوا در داخل کانتینر،
متغیر محیطی \fBTZ\fR باید درون کانتینر تنظیم شود. برنامه‌های جاوا مقدار تنظیم‌شده با
گزینه \fB--tz\fR را نادیده می‌گیرند.

.EX
# Example run
podman run -ti --rm  -e TZ=EST mytzimage
lrwxrwxrwx. 1 root root 29 Nov  3 08:51 /etc/localtime -> ../usr/share/zoneinfo/Etc/UTC
Now with default timezone:
Fri Nov 19 18:10:55 EST 2021
Java default sees the following timezone:
2021-11-19T18:10:55.651130-05:00
Forcing UTC:
Fri Nov 19 23:10:55 UTC 2021
.EE

.SS اجرای یک کانتینر متصل به دو شبکه (به نام‌های net1 و net2) با آی‌پی ثابت
.EX
$ podman run --network net1:ip=10.89.1.5 --network net2:ip=10.89.10.10 alpine ip addr
.EE

.SS تعریف بررسی سلامت در زمان اجرا و تایید آن
.EX
$ podman create -d --name healthcheck-example -p 8080:80   
  --health-cmd '["CMD-SHELL","wget -q --spider http://127.0.0.1:80 || exit 1"]'   
  --health-interval 30s --health-timeout 5s --health-retries 3   
  docker.io/library/nginx:alpine

$ podman inspect healthcheck-example | jq '.[0].State.Health'
.EE

.SS کانتینرهای بدون ریشه (Rootless Containers)
پادمن در اکثر سیستم‌ها به عنوان یک کاربر غیر ریشه اجرا می‌شود. این قابلیت نیازمند نصب نسخه به قدر کافی جدیدی از \fBshadow-utils\fP
است. بسته \fBshadow-utils\fP باید شامل فایل‌های اجرایی \fBnewuidmap\fP(1) و \fBnewgidmap\fP(1) باشد.

.PP
برای اینکه کاربران بتوانند به صورت بدون ریشه اجرا کنند، باید ورودی‌ای برای نام کاربری آن‌ها در \fI/etc/subuid\fP و \fI/etc/subgid\fP وجود داشته باشد که UIDهای فضای نام کاربری آن‌ها را مشخص نماید.

.PP
پادمن بدون ریشه در صورت نصب بودن بسته fuse-overlayfs عملکرد بهتری دارد.
بسته \fBfuse-overlayfs\fP یک درایور ذخیره‌سازی overlay در فضای کاربری فراهم می‌کند، در غیر این صورت کاربران باید
از درایور ذخیره‌سازی \fBvfs\fP استفاده کنند که می‌تواند فضای دیسک زیادی مصرف کرده و کارایی کمتری نسبت به سایر درایورها داشته باشد.

.PP
برای فعال‌سازی VPN روی کانتینر، به طور پیش‌فرض از شبکه pasta استفاده می‌شود؛
در غیر این صورت، کانتینرها باید با پرچم --network=host اجرا شوند.

.SH "محیط (ENVIRONMENT)"
متغیرهای محیطی درون کانتینرها را می‌توان با چندین گزینه مختلف و با ترتیب اولویت زیر تنظیم کرد (ورودی‌های بعدی ورودی‌های قبلی را بازنویسی می‌کنند):
.IP \(bu 2
ایمیج کانتینر: هرگونه متغیر محیطی مشخص‌شده در ایمیج کانتینر.
.IP \(bu 2
\fB--http-proxy\fP: به طور پیش‌فرض، چندین متغیر محیطی از میزبان منتقل می‌شوند، مانند \fBhttp_proxy\fP و \fBno_proxy\fP\&. برای جزئیات به \fB--http-proxy\fP مراجعه کنید.
.IP \(bu 2
\fB--env-host\fP: محیط میزبان فرایندی که پادمن را اجرا می‌کند اضافه می‌شود.
.IP \(bu 2
\fB--env-file\fP: هرگونه متغیر محیطی مشخص‌شده از طریق env-files. اگر چندین فایل مشخص شوند، به ترتیب ورود یکدیگر را بازنویسی می‌کنند.
.IP \(bu 2
\fB--env\fP: هرگونه متغیر محیطی مشخص‌شده تنظیمات قبلی را بازنویسی می‌کند.

.PP
اجرای کانتینرها و تنظیم محیط با متغیرهایی که به \fB*\fP ختم می‌شوند.
قابلیت glob با علامت \fB*\fP پایانی تنها زمانی فعال است که مقداری مشخص نشده باشد:

.EX
$ export ENV1=a
$ podman run --env 'ENV*' alpine env | grep ENV
ENV1=a
$ podman run --env 'ENV*=b' alpine env | grep ENV
ENV*=b
.EE

.SH "کانمون (CONMON)"
هنگامی که پادمن کانتینری را راه‌اندازی می‌کند، در واقع برنامه conmon را اجرا می‌کند که
سپس OCI Runtime را اجرا می‌نماید. Conmon ناظر کانتینر (container monitor) است. این یک برنامه کوچک است
که وظیفه دارد فرایند اصلی کانتینر را نظارت کند و در صورت متوقف شدن کانتینر، کد خروج آن را ذخیره نماید.
همچنین tty کانتینر را باز نگه می‌دارد تا بعداً بتوان به آن متصل شد. این همان چیزی است که به پادمن
اجازه می‌دهد در حالت جداشده (detached / پس‌زمینه) اجرا شود، به‌طوری‌که پادمن خارج می‌شود اما conmon به اجرا ادامه می‌دهد.
هر کانتینر نمونه اختصاصی conmon خود را دارد. Conmon منتظر خروج کانتینر می‌ماند، کد خروج را جمع‌آوری و ذخیره می‌کند
و سپس یک فرایند پادمن را برای تکمیل پاک‌سازی کانتینر از طریق خاموش کردن شبکه و فضای ذخیره‌سازی راه‌اندازی می‌نماید.
برای اطلاعات بیشتر در مورد conmon، به صفحه راهنمای conmon(8) مراجعه کنید.

.SH "فایل‌ها (FILES)"
\fB/etc/subuid\fP

.PP
\fB/etc/subgid\fP

.PP
نکته: از متغیر محیطی \fBTMPDIR\fR برای تغییر مکان ذخیره‌سازی موقت ایمیج‌های کانتینر دانلودشده استفاده کنید. پیش‌فرض پادمن استفاده از \fB/var/tmp\fR است.

.SH "همچنین ببینید (SEE ALSO)"
\fBpodman(1)\fP, \fBpodman-save(1)\fP, \fBpodman-ps(1)\fP, \fBpodman-attach(1)\fP, \fBpodman-pod-create(1)\fP, \fBpodman-port(1)\fP, \fBpodman-start(1)\fP, \fBpodman-kill(1)\fP, \fBpodman-stop(1)\fP, \fBpodman-generate-systemd(1)\fP, \fBpodman-rm(1)\fP, \fBsubgid(5)\fP, \fBsubuid(5)\fP, \fBcontainers.conf(5)\fP, \fBpodman-systemd.unit(5)\fP, \fBsetsebool(8)\fP, \fBpasta(1)\fP, \fBfuse-overlayfs(1)\fP, \fBproc(5)\fP, \fBconmon(8)\fP, \fBpersonality(2)\fP

.SS عیب‌یابی (Troubleshooting)
صفحه podman-troubleshooting(7) را برای راه‌حل‌های مشکلات رایج ببینید.

.PP
صفحه podman-rootless(7) را برای مشکلات مربوط به حالت بدون ریشه ببینید.

.SH "تاریخچه (HISTORY)"
سپتامبر ۲۰۱۸، به‌روزرسانی توسط کونال کوشواها (Kunal Kushwaha) \fB<kushwaha_kunal_v7@lab.ntt.co.jp>\fR

.PP
اکتبر ۲۰۱۷، تبدیل از مستندات داکر به پادمن توسط دن والش برای پادمن \fB<dwalsh@redhat.com>\fR

.PP
نوامبر ۲۰۱۵، به‌روزرسانی توسط سالی اومالی (Sally O'Malley) \fB<somalley@redhat.com>\fR

.PP
ژوئن ۲۰۱۴، به‌روزرسانی توسط اسون داویدایت (Sven Dowideit) \fB<SvenDowideit@home.org.au>\fR

.PP
آوریل ۲۰۱۴، گردآوری اولیه توسط ویلیام هنری (William Henry) \fB<whenry@redhat.com>\fR بر اساس مطالب docker.com و کارهای داخلی.

.SH "پاورقی‌ها (FOOTNOTES)"
1: پروژه پادمن متعهد به همه‌شمولی و فراگیری است که از ارزش‌های بنیادین نرم‌افزار آزاد و متن‌باز به شمار می‌رود. اصطلاحات انتشار مانت \fBmaster\fR و \fBslave\fR که در اینجا استفاده شده‌اند چالش‌برانگیز و تفرقه‌انگیز بوده و نیازمند بازنگری هستند. با این وجود، این اصطلاحات در حال حاضر درون کرنل لینوکس استفاده می‌شوند و در این بازه زمانی باید دقیقاً همان‌گونه به کار روند. به محض اینکه نگه‌دارندگان کرنل این اصطلاحات را اصلاح کنند، پروژه پادمن نیز فوراً همان رویه را دنبال خواهد کرد.