Docker Compose میں PUID اور PGID کیا کرتے ہیں؟

PUID اور PGID دراصل کیا ہیں

PUID اور PGID دو environment variables ہیں جنہیں کچھ container images startup کے وقت پڑھتی ہیں۔ Docker خود انہیں کبھی نہیں پڑھتا۔ یہ ایک convention ہے جسے linuxserver.io images اور چند دیگر images استعمال کرتی ہیں۔ اس لیے جو image ان variables کو پڑھنے کے لیے نہیں بنائی گئی، وہ انہیں خاموشی سے نظر انداز کر دیتی ہے۔

linuxserver.io image کے اندر abc نام کا ایک user ہوتا ہے۔ اسے build کے وقت UID (user ID) 911 اور GID (group ID) 911 کے ساتھ بنایا جاتا ہے۔ Container root کے طور پر start ہوتا ہے، اپنے init scripts چلاتا ہے، اور ان scripts میں سے ایک، باقی تمام کام شروع ہونے سے پہلے، اس user کے IDs تبدیل کرتی ہے:

groupmod -o -g "${PGID}" abc
usermod -o -u "${PUID}" abc

-o flag ایسا ID استعمال کرنے کی اجازت دیتا ہے جو پہلے ہی کسی دوسری جگہ استعمال ہو رہا ہو۔ اس کے بعد init privileges کم کرتا ہے اور application کو abc کے طور پر چلاتا ہے۔ اس لیے PUID=1000 کبھی Docker تک نہیں پہنچتا۔ یہ variable application start ہونے سے پہلے container کے اندر ایک user کا ID تبدیل کرتا ہے۔ نتیجتاً application کی لکھی ہوئی ہر file آپ کی disk پر 1000 کی ملکیت میں محفوظ ہوتی ہے۔ PUID کو unset چھوڑنے پر abc کا ID 911 ہی رہتا ہے۔ اسی لیے غیر configured bind mount ایسی files سے بھر جاتا ہے جن کا مالک 911:911 ہوتا ہے۔

اپنے دونوں اعداد id سے حاصل کریں

یہ کمانڈ host پر اس user کے طور پر چلائیں جو data directories کا مالک ہے:

id

uid=1000(deploy) gid=1000(deploy) groups=1000(deploy),27(sudo),988(docker)

uid آپ کا PUID ہے اور gid آپ کا PGID ہے۔ Script میں id -u اور id -g صرف اعداد print کرتے ہیں۔ زیادہ تر نئے VPS images میں پہلا human account 1000:1000 ہوتا ہے، لیکن اسے فرض نہ کریں۔ Rebuilt server یا بعد میں شامل کیا گیا دوسرا account 1001 یا اس سے زیادہ دے سکتا ہے، اور یہاں غلط عدد ہی پورا مسئلہ ہوتا ہے۔ اگر آپ کی services اپنے login user کے بجائے dedicated service account کے تحت چلتی ہیں تو id thatuser چلائیں اور وہاں سے اعداد حاصل کریں۔

آپ کی فائلیں 911:911 کے طور پر کیوں ظاہر ہوتی ہیں

ls -l اس وقت نام کے بجائے عددی ID دکھاتا ہے جب اس ID سے مطابقت رکھنے والا کوئی host account موجود نہ ہو۔ آپ کے server پر UID 911 موجود نہیں، اس لیے دکھانے کے لیے کوئی نام نہیں ہے۔ ہر بار اعداد دیکھنے اور اس ابہام کو ختم کرنے کے لیے ls -ln استعمال کریں:

ls -ln /srv/appdata/sonarr

drwxr-xr-x 2 911 911 4096 Aug  7 09:12 Backups
-rw-r--r-- 1 911 911  512 Aug  7 09:12 config.xml

اس output سے معلوم ہوتا ہے کہ container نے built-in defaults کے ساتھ run کیا۔ اندازہ لگانے کے بجائے container کے اندر سے اس کی تصدیق کریں:

docker exec sonarr id abc
docker compose logs sonarr | head -n 25

linuxserver init اپنا نتیجہ startup log میں دو سطروں کے طور پر دکھاتا ہے:

User UID:    911
User GID:    911

اگر آپ کی Compose file میں PUID=1000 set کرنے کے بعد بھی ان سطروں میں 911 لکھا ہو تو variable container تک نہیں پہنچا۔ عام وجہ یہ ہے کہ آپ نے docker-compose.yml میں ترمیم کی اور پھر docker compose restart چلایا، جو موجودہ container کو اس کے اصل environment کے ساتھ دوبارہ استعمال کرتا ہے۔ Environment میں تبدیلیوں کے لیے docker compose up -d درکار ہے، جو container کو دوبارہ بناتا ہے۔

آپ container کی لکھی ہوئی file کیوں delete نہیں کر سکتے

kernel صرف numbers کا موازنہ کرتا ہے، names کا نہیں۔ آپ کا shell UID 1000 کے طور پر چلتا ہے۔ file کی ملکیت UID 911 کے پاس ہے۔ اسے رکھنے والی directory drwxr-xr-x ہے اور وہ بھی 911 کی ملکیت ہے، اس لیے group اور other کو read اور execute کی اجازت ملتی ہے، لیکن write کی نہیں۔ file delete کرنے کے لیے file پر نہیں بلکہ اس کی directory پر write permission درکار ہوتی ہے۔ اسی لیے یہ صورت حال اس وقت بھی پیش آتی ہے جب file خود بظاہر بے ضرر ہو:

rm: cannot remove '/srv/appdata/sonarr/config.xml': Permission denied

لکھنے والا container بھی دوسری سمت سے اسی رکاوٹ سے دوچار ہوتا ہے۔ اگر host directory آپ کے user کی ملکیت ہو اور اس کا mode 755 ہو، جبکہ application 911 کے طور پر چل رہی ہو، تو اس کی پہلی write Permission denied کے ساتھ ناکام ہو جاتی ہے اور app اسے اپنے الفاظ میں report کرتی ہے۔ Sonarr یا Radarr جیسی .NET application میں یہ UnauthorizedAccessException: Access to the path '/data/downloads' is denied کے طور پر ظاہر ہوتا ہے۔ file کے شروع میں موجود permission string بتاتی ہے کہ تین permission sets میں سے کس کے مطابق آپ کی رسائی جانچی جا رہی ہے۔ drwxr-xr-x کو درست طور پر پڑھنا اس error کو پراسرار کے بجائے واضح بنا دیتا ہے۔

یہ خاص طور پر bind mount کا مسئلہ ہے۔ جب Docker ایک empty named volume بناتا ہے اور اسے image میں موجود path پر mount کرتا ہے، تو وہ اس path کا content، ownership اور permission bits سمیت، volume میں copy کر دیتا ہے۔ یوں application کو ایسی directory ملتی ہے جس کی ملکیت پہلے ہی اس کے پاس ہوتی ہے۔ bind mount کو یہ سہولت نہیں ملتی: Docker آپ کی host directory کو بالکل اسی حالت میں mount کرتا ہے جس حالت میں وہ موجود ہو۔ یہی فرق ان عملی وجوہات میں شامل ہے جن کی بنا پر یہ جاننا ضروری ہے کہ bind mount کب named volume سے بہتر ہے اور کب نہیں۔

پہلے سے غلط directory کو درست کرنا

PUID اور PGID سیٹ کرنے سے ایپلیکیشن کے آئندہ کے رویے میں تبدیلی آتی ہے۔ اس سے disk پر پہلے سے موجود فائلیں خودکار طور پر درست نہیں ہوتیں۔ stack کو روکیں، خود ownership درست کریں، پھر اسے دوبارہ شروع کریں:

docker compose down
sudo chown -R 1000:1000 /srv/appdata/sonarr
docker compose up -d

اگر آپ numbers خود درج نہیں کرنا چاہتے تو sudo chown -R "$(id -u):$(id -g)" /srv/appdata/sonarr استعمال کریں۔ یہ کام container کے رکے ہوئے ہونے کی حالت میں کریں، کیونکہ recursive chown کے دوران لکھنے میں مصروف ایپلیکیشن directory tree کو جزوی طور پر درست کر سکتی ہے، جس سے errors کا دوسرا اور مبہم سلسلہ پیدا ہو سکتا ہے۔

PUID اور PGID کیا درست نہیں کرتے

یہ وہ حصہ ہے جہاں درست اقدامات کرنے والے لوگ بھی مشکل میں پڑ جاتے ہیں۔ linuxserver init startup کے وقت عین تین paths پر chown چلاتا ہے: /app، /config اور /defaults۔ آپ کے media mounts اس فہرست میں شامل نہیں ہیں۔ /data، /downloads اور /tv کو application کے حوالے بغیر کسی تبدیلی کے کیا جاتا ہے۔ لہٰذا اگر ان mounts کے host side پر ایسی ownership ہو جس میں container user لکھ نہ سکے، تو container صاف طور پر start ہوتا ہے، اپنے banner میں درست UID دکھاتا ہے، اور پھر پہلے import پر fail ہو جاتا ہے۔

یہی درست رویہ ہے۔ ہر container start پر بارہ terabyte کی media library پر recursive chown چلانا تباہ کن ہوگا۔ اس کا مطلب یہ ہے کہ media directories کی ذمہ داری آپ کی ہے، اور permissions کی اصل خرابی عموماً انہی mounts میں ہوتی ہے۔

صارف کو کنٹرول کرنے کے 3 طریقے، اور ہر طریقہ کب لاگو ہوتا ہے

PUID اور PGID environment variables

یہ صرف ان images پر کام کرتا ہے جن کا entrypoint انہیں پڑھتا ہے۔ یہ طریقہ مقبول ہے کیونکہ container ابتدا میں root کے طور پر start ہوتا ہے، اپنا setup مکمل کرتا ہے، /config درست کرتا ہے، اور اس کے بعد ہی privileges کم کرتا ہے۔ Docker Mods اور custom init scripts بھی کام کرتے رہتے ہیں۔ اس کی قیمت یہ ہے کہ آپ platform feature کے بجائے ایک convention پر اعتماد کر رہے ہوتے ہیں، اور variable names مختلف projects میں standard نہیں ہوتے۔

Compose میں user: key

یہ حقیقی Docker feature ہے اور ہر image پر کام کرتا ہے، کیونکہ container runtime اسے image کے اپنے code کے چلنے سے پہلے لاگو کرتا ہے:

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    user: "1000:1000"

Process کبھی بھی root کے طور پر نہیں چلتا، ایک لمحے کے لیے بھی نہیں۔ یہ حقیقی security gain ہے۔ تاہم entrypoint میں root درکار ہر چیز بھی کام کرنا بند کر دیتی ہے۔ linuxserver images میں project اسے reasonable endeavours basis پر سپورٹ کرتا ہے، اور صرف ان images کے لیے جنہیں اس نے test کیا ہو۔ اس کے مخصوص caveats ہیں: PUID اور PGID کا کوئی اثر نہیں رہتا، Docker Mods نہیں چلیں گے، custom services نہیں چلیں گی، اور ہر mounted volume کی permissions کی ذمہ داری آپ پر ہوگی۔ ان کی documented pattern میں اس flag کے ساتھ writable /run استعمال کیا جاتا ہے:

user: 1000:1000
tmpfs:
  - /run:uid=1000,gid=1000,exec
security_opt:
  - no-new-privileges=true

ایک cosmetic side effect لوگوں کو حیران کرتا ہے۔ Numeric user: کا container کے /etc/passwd میں matching entry نہیں ہوتا، اس لیے اندر موجود tools whoami: cannot find name for user ID 1000 report کرتے ہیں۔ ID valid ہوتی ہے اور file access معمول کے مطابق کام کرتا ہے۔ صرف name lookup ناکام ہوتا ہے۔

Rootless Docker

Rootless Docker daemon کو خود آپ کے unprivileged user کے طور پر چلاتا ہے، اس لیے machine پر کوئی چیز حقیقی root کے طور پر نہیں چلتی۔ اس سے ownership arithmetic مکمل طور پر بدل جاتی ہے۔ Container UID 0، rootless Docker چلانے والے host user کے UID سے map ہوتا ہے۔ Container UID n، جہاں n کی قدر 1 یا اس سے زیادہ ہو، subuid + (n - 1) سے map ہوتا ہے۔ subuid، /etc/subuid میں آپ کے لیے allocated range کی base ہے، اور /etc/subgid اس range سے متعلق ہے۔ Docker کو وہاں کم از کم 65,536 subordinate IDs درکار ہوتی ہیں۔

اس mapping کو دوبارہ پڑھیں، کیونکہ یہ عام مشورے کے الٹ ہے۔ Rootless Docker کے تحت root کے طور پر لکھنے والا container ایسی files بناتا ہے جن کی ownership آپ کے پاس ہوتی ہے۔ UID 1000 کے طور پر لکھنے والا container ایسی files بناتا ہے جن کی ownership تقریباً 100999 جیسے subordinate ID کے پاس ہوتی ہے، اور آپ کا shell انہیں access نہیں کر سکتا۔ اس لیے rootful daemon پر درست PUID value یہاں غلط ہوتی ہے۔ دونوں mechanisms مختلف layers میں ایک ہی مسئلے کو حل کرتے ہیں، اور بغیر جانچ کے انہیں stack کرنے سے ایسی directory بن سکتی ہے جسے remove کرنے کے لیے آپ کو sudo درکار ہو۔ اگر آپ rootless استعمال کریں تو library migrate کرنے سے پہلے اپنے server پر لکھی گئی ایک file کی ownership test کریں۔

ایک single VPS پر زیادہ تر self-hosted stacks کے لیے rootful daemon کے ساتھ PUID اور PGID عملی انتخاب ہیں، کیونکہ images اسی configuration کے لیے بنائی اور document کی گئی ہیں۔ user: اس وقت استعمال کریں جب image README میں کہا گیا ہو کہ image کو اس کے ساتھ test کیا گیا ہے، یا جب آپ کوئی official upstream image چلا رہے ہوں جس میں PUID support موجود نہ ہو۔ Document workspace، مثلاً ایک self-hosted AFFiNE instance جو ایک VPS پر ہو، دوسری صورت میں آتا ہے، کیونکہ اس کے کوئی بھی containers PUID نہیں پڑھتے۔ اس کی database directory اور uploaded files کی ownership environment block کے بجائے runtime طے کرتا ہے۔

میڈیا stack کا عملی معاملہ: containers کے درمیان ایک مشترکہ group

ایک arr media stack جس میں Sonarr، Radarr اور download client شامل ہوں وہ جگہ ہے جہاں یہ مسئلہ نظری نہیں رہتا۔ download client مکمل فائل کو /data/downloads میں لکھتا ہے۔ اس کے بعد Sonarr اس فائل کا hardlink بناتا ہے یا اسے /data/media میں منتقل کرتا ہے۔ hardlink کے لیے دونوں containers کو اسی tree تک write access درکار ہوتا ہے۔ اگر download client 1000 کے طور پر چل رہا ہو جبکہ Sonarr 1001 کے طور پر چل رہا ہو، تو ان میں سے ایک ایسی فائلوں کا مالک ہوگا جنہیں دوسرا صرف پڑھ سکے گا۔

حل یہ ہے کہ ایک مشترکہ group بنایا جائے جسے stack کا ہر container اپنے PGID کے طور پر استعمال کرے:

sudo groupadd -g 13000 media
sudo usermod -aG media deploy
sudo chown -R deploy:media /srv/media
sudo find /srv/media -type d -exec chmod 2775 {} +
sudo find /srv/media -type f -exec chmod 0664 {} +

2775 میں شروع کا 2 setgid bit ہے۔ directory پر اس کا مطلب ہے کہ اس کے اندر بننے والی ہر نئی file اور subdirectory، بنانے والے کے اپنے primary group کے بجائے group media inherit کرے گی۔ اس طرح نئی downloads کے بعد آپ کو دوبارہ chown چلانے کی ضرورت نہیں رہتی۔ اپنی access چیک کرنے سے پہلے log out کرکے دوبارہ log in کریں، یا newgrp media چلائیں۔ usermod -aG سے شامل کیا گیا group پہلے سے کھلے ہوئے shell session میں ظاہر نہیں ہوتا۔

container کے اندر groupmod -o -g 13000 abc، abc group کو 13000 پر renumber کرتا ہے۔ اس سے abc آپ کے host کے media group کے برابر GID کے ساتھ فائلیں لکھتا ہے۔ stack کا ہر container اپنا PUID برقرار رکھتا ہے اور یہی ایک PGID مشترکہ طور پر استعمال کرتا ہے۔

اس کے بعد stack میں موجود ہر linuxserver container پر UMASK=002 مقرر کریں۔ اکثر لوگ یہی مرحلہ چھوڑ دیتے ہیں۔ ان images میں default UMASK=022 ہوتا ہے، جو ہر نئی file سے group write bit ہٹا دیتا ہے۔ اس کے نتیجے میں فائلیں 0644 کے طور پر بنتی ہیں، اور آپ کی ابھی کی گئی sharing configuration بے اثر ہو جاتی ہے۔ 002 سے 0664 فائلیں اور 0775 directories بنتی ہیں، جن میں group لکھ سکتا ہے:

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=002
      - TZ=Etc/UTC
    volumes:
      - /srv/appdata/sonarr:/config
      - /srv/media:/data
    restart: unless-stopped

یہ دونوں values Compose file کے ساتھ موجود .env file میں ہونی چاہییں، تاکہ پورا stack ایک ہی definition پڑھے:

PUID=1000
PGID=13000

Compose اس file کو ${PUID} طرز کی substitution کے لیے خودکار طور پر پڑھتا ہے۔ یہی mechanism آپ credentials کے لیے بھی استعمال کرتے ہیں۔ values کو docker-compose.yml سے باہر رکھ کر .env file میں رکھنے کے اصول یہاں بھی لاگو ہوتے ہیں، مگر فرق یہ ہے کہ یہ دونوں numbers secret نہیں ہیں۔

صرف configuration پر اعتماد کرنے کے بجائے اسے شروع سے آخر تک verify کریں۔ ایک container کے اندر file لکھیں اور اسے host سے پڑھیں:

docker exec sonarr touch /data/downloads/permtest
ls -ln /srv/media/downloads/permtest

درست نتیجے میں owner کے طور پر آپ کا PUID، group کے طور پر 13000، اور mode کے طور پر -rw-rw-r-- دکھائی دے گا۔ اگر group 1000 پڑھا جائے تو اس directory میں setgid bit موجود نہیں ہے۔ اگر mode -rw-r--r-- پڑھا جائے تو UMASK variable مؤثر نہیں ہوا۔ اس لیے چیک کریں کہ آپ نے container کو recreate کیا ہے، صرف restart نہیں کیا۔ کام مکمل ہونے پر test file کو rm /srv/media/downloads/permtest سے حذف کریں۔

کون سی images کون سا variable استعمال کرتی ہیں

linuxserver.io کی images PUID، PGID اور UMASK استعمال کرتی ہیں۔ Paperless-ngx اسی تصور کے لیے مختلف نام استعمال کرتا ہے: USERMAP_UID اور USERMAP_GID، جن کی default value دونوں کے لیے 1000 ہے۔ اس کی documentation میں بتایا گیا ہے کہ یہ values id -u اور id -g سے پڑھی جائیں۔ Photo servers میں بھی یہی فرق موجود ہے: PhotoPrism کا اپنا PHOTOPRISM_UID اور PHOTOPRISM_GID کا جوڑا ہے، جبکہ Immich میں اس کا کوئی equivalent شامل نہیں ہوتا۔ یہ container user کے لیے Docker کی user: key استعمال کرتا ہے۔ اس لیے PhotoPrism اور Immich میں انتخاب یہ بھی طے کرتا ہے کہ سرور کی سب سے بڑی library کے لیے آپ کو ان میں سے کون سا mechanism maintain کرنا ہوگا۔ بہت سی official upstream images، جن میں عام database اور web server images شامل ہیں، ایک fixed built-in user کے ساتھ آتی ہیں اور توقع کرتی ہیں کہ آپ user: استعمال کریں یا اسے تبدیل نہ کریں۔ بعد میں شامل کیے جانے والے infrastructure پر بھی یہی بات لاگو ہوتی ہے۔ اس لیے ایک ہی login کے لیے اپنی apps کے سامنے Authentik چلانے کا مطلب official server، Postgres اور Redis images چلانا ہے۔ یہ images PUID بالکل نہیں پڑھتیں، اور ان کی volumes کی ownership runtime سے آتی ہے، نہ کہ ایسے entrypoint سے جسے آپ configure کر سکیں۔

اس لیے projects کے درمیان environment block نقل کرنے سے پہلے ہر image کی README دیکھیں۔ Docker آپ کی مقرر کردہ ہر environment variable کو ہر container میں منتقل کرتا ہے، خواہ container کے اندر کوئی چیز اسے پڑھتی ہو یا نہیں۔ اگر PUID کو کوئی چیز استعمال نہ کرے تو اس سے کوئی error، warning یا اثر پیدا نہیں ہوتا۔ Container اپنے Dockerfile میں آخری مرتبہ مقرر کیے گئے user کے طور پر چلتا ہے، اور اس کا پتا ان files کی ownership سے چلتا ہے جو وہ لکھتا ہے۔

FAQ

میری Docker فائلوں کی ملکیت 911:911 کیوں ہے؟

911، abc صارف کا UID اور GID ہے، جو linuxserver.io images میں شامل ہوتا ہے۔ اس کا مطلب ہے کہ container، PUID اور PGID کے بغیر شروع ہوا، اس لیے اس کے init script نے built-in defaults برقرار رکھے۔ ls -l خام نمبرز دکھاتا ہے، کیونکہ آپ کے host پر ID 911 والا کوئی account موجود نہیں؛ اسی لیے دکھانے کے لیے کوئی نام نہیں ہے۔ PUID اور PGID کو id کے output پر set کریں، docker compose up -d کے ساتھ container دوبارہ بنائیں، پھر متاثرہ directory میں موجود فائلوں کی ملکیت sudo chown -R 1000:1000 سے درست کریں۔

کیا PUID اور PGID ہر Docker image پر کام کرتے ہیں؟

نہیں۔ یہ Docker feature نہیں ہیں، اور Docker انہیں کبھی read نہیں کرتا۔ یہ صرف ان images پر کام کرتے ہیں جن کا اپنا entrypoint انہیں read کرتا ہے اور application شروع کرنے سے پہلے usermod اور groupmod چلاتا ہے۔ linuxserver.io family اور چند ایسے projects اسی pattern کو استعمال کرتے ہیں۔ دیگر projects مختلف نام استعمال کرتے ہیں، مثلاً paperless-ngx میں USERMAP_UID اور USERMAP_GID۔ ایسی image پر جو ان میں سے کسی variable کو read نہیں کرتی، یہ variables قبول کر کے خاموشی سے نظرانداز کر دیے جاتے ہیں۔

کیا Docker Compose میں PUID اور PGID یا user: key استعمال کرنی چاہیے؟

جب image انہیں support کرتی ہو تو PUID اور PGID استعمال کریں، کیونکہ entrypoint اتنی دیر root کے طور پر چلتا ہے کہ /config درست کر سکے اور اپنی services صحیح طور پر شروع کر سکے۔ جب image میں PUID support نہ ہو، یا image README میں non-root operation کی testing کی تصدیق ہو، تو user: استعمال کریں۔ linuxserver image پر user: set کرنے سے PUID اور PGID غیر مؤثر ہو جاتے ہیں، Docker Mods اور custom services چلنا بند ہو جاتی ہیں، اور mounted volumes کی permissions کی مکمل ذمہ داری آپ پر آ جاتی ہے۔

Sonarr کے پاس درست PUID ہے، لیکن پھر بھی فائلیں منتقل نہیں کر سکتا۔ مسئلہ کیا ہے؟

تین چیزیں اسی ترتیب سے check کریں۔ پہلی چیز media mount خود ہے: init صرف /app، /config اور /defaults کی ملکیت تبدیل کرتا ہے، اس لیے /data یا /downloads host پر موجود اپنی موجودہ ملکیت برقرار رکھتا ہے۔ دوسری چیز shared group ہے: اگر download client اور Sonarr مختلف GIDs کے تحت چلیں تو دونوں ایک دوسرے کی فائلوں میں ترمیم نہیں کر سکتے؛ اس لیے stack کے ہر container کو ایک ہی PGID دیں۔ تیسری چیز umask ہے: image کا default UMASK=022 فائلیں 0644 کے طور پر بناتا ہے اور group write bit شامل نہیں کرتا، جس سے shared group مکمل طور پر غیر مؤثر ہو جاتا ہے۔ UMASK=002 set کریں، اور chmod 2775 کے ذریعے directories پر setgid bit set کریں تاکہ نئی فائلیں group inherit کریں۔