Compose: डॉकर कंपोज़ माउंट्स ने वॉल्यूम को विशेष रूप से 'रूट' के रूप में नामित किया है

मुझे नहीं लगता कि यह डॉकर इंजन द्वारा समर्थित है, इसलिए जब तक इसे एपीआई में नहीं जोड़ा जाता है, तब तक हम इसे कंपोज़ में समर्थन नहीं कर सकते हैं। हालाँकि मुझे नहीं लगता कि इस सुविधा को जोड़ना आवश्यक है। आप फ़ाइलों को हमेशा सही उपयोगकर्ता को दिखा सकते हैं:

version: '2'
services:
  web:
    image: alpine:3.3
    volumes: ['random:/path']

volumes:
  random:

$ docker-compose run web sh
/ # touch /path/foo
/ # ls -l /path
total 0
-rw-r--r--    1 root     root             0 Apr  5 16:11 foo
/ # chown postgres:postgres /path/foo
/ # ls -l /path
total 0
-rw-r--r--    1 postgres postgres         0 Apr  5 16:11 foo
/ # 

$ docker-compose run web sh
/ # ls -l /path
total 0
-rw-r--r--    1 postgres postgres         0 Apr  5 16:11 foo

आप जिस समस्या का सामना कर रहे हैं वह एक नामित वॉल्यूम को प्रारंभ करने के बारे में है। यह स्वीकार्य रूप से ऐसा कुछ नहीं है जिसे कंपोज़ द्वारा नियंत्रित किया जाता है (क्योंकि यह कुछ हद तक दायरे से बाहर है), लेकिन आप docker-compose up चलाने से पहले नामित वॉल्यूम को प्रारंभ करने के लिए आसानी से डॉकर क्ली का उपयोग कर सकते हैं।

मुझे वास्तव में यकीन नहीं था कि यह डॉकर या कंपोज़ समस्या थी, क्षमा करें यदि मैंने इसे गलत तरीके से दर्ज किया है।
क्या यह डॉकर एपीआई में एक योजना है, क्या मुझे वहां कोई समस्या दर्ज करनी चाहिए?

मैं कंटेनर में मैन्युअल रूप से लॉग इन करने और chown को 'पोस्टग्रेज' उपयोगकर्ता को वॉल्यूम देने की संभावना को समझता हूं। लेकिन बात यह है कि, मेरे मामले में, मैं कंपोज़ का उपयोग कर रहा हूं, इसलिए मैं तुरंत नए ग्राहकों ( docker-compose -p client_name up ) के लिए नए कंटेनरों का उदाहरण दे सकता हूं और कंपोज़ एक कस्टम नेटवर्क client_name_default बनाएगा, यह कंटेनर बनाएगा client_name _appserver_1 और client_name _server-postgresql_1 और _अधिक महत्वपूर्ण रूप से नामों के साथ, यह वॉल्यूम client_name_db-data बनाएगा। जिनमें से सभी को मुझे मैन्युअल रूप से करने की ज़रूरत नहीं है, इसलिए इसे स्क्रिप्ट द्वारा चलाया जा सकता है जो क्लाइंट पंजीकरण को संभालता है।

आपके द्वारा वर्णित समाधान के साथ (_manually_ "लॉगिंग" कंटेनर में sh और chown वॉल्यूम लेबल के साथ), मेरे पास नए क्लाइंट जोड़ने के लिए एक सरल प्रक्रिया नहीं हो सकती है, और यह होना चाहिए हाथ से देखभाल की जाएगी।

इसलिए मुझे लगता है कि इस सुविधा को लागू किया जाना चाहिए। डॉकर एपीआई में, हम वॉल्यूम बढ़ते समय ro या rw (केवल-पढ़ने या पढ़ने-लिखने के लिए) अनुमतियां निर्दिष्ट कर सकते हैं, मुझे लगता है कि हमें user:group निर्दिष्ट करने में सक्षम होना चाहिए

आपको क्या लगता है, क्या मेरे अनुरोध का कोई मतलब है?

वास्तव में मैं यहां समाचार लेकर आया हूं, ऐसा लगता है कि मैं जो हासिल करने की कोशिश कर रहा हूं वह संभव है, लेकिन मुझे नहीं पता कि यह एक विशेषता या बग है। यही कारण है कि मैं बदल गया:

मेरे Dockerfile में , _उपयोगकर्ता 'postgres'_ में बदलने से पहले मैंने इन्हें जोड़ा:

# ...
RUN    mkdir /volume_data
RUN   chown postgres:postgres /volume_data

USER postgres
# ...

यह जो करता है वह एक निर्देशिका /volume_data बनाता है और इसकी अनुमतियों को बदलता है ताकि उपयोगकर्ता 'पोस्टग्रेज' उस पर लिख सकें।
यह डॉकरफाइल हिस्सा है।

अब मैंने docker-compose.yml पर कुछ भी नहीं बदला है: इसलिए directory_name_db-data बनाता है और इसे /volume_data माउंट करता है और अनुमतियां बनी रहती हैं! .
जिसका अर्थ है कि अब, मेरे पास _pre-मौजूदा_ निर्देशिका /volume_data संरक्षित अनुमतियों के साथ मेरा नामांकित वॉल्यूम आरोहित है, इसलिए 'पोस्टग्रेज' इसे लिख सकता है।

तो अगर यह इरादा व्यवहार या सुरक्षा का उल्लंघन है? (हालांकि, इस मामले में यह मेरी सेवा करता है!)

मेरा मानना ​​​​है कि इसे डॉकर 1.10.x में जोड़ा गया था ताकि नामित संस्करणों को पहले कंटेनर से शुरू किया जा सके जो उनका इस्तेमाल करते थे। मुझे लगता है कि यह अपेक्षित व्यवहार है।

मैं डॉकरफाइल में स्वामित्व के साथ नामित वॉल्यूम भी कर रहा हूं और रचना में मैं user: postgres जोड़ रहा हूं ताकि पीआईडी ​​​​1 भी गैर-रूट उपयोगकर्ता के स्वामित्व में हो।

Docker-compose लिए volumes में विकल्प प्रदान करने के लिए driver_opts है।
chmod , chown यहां तक ​​कि ड्राइवर के लिए भी local जैसे विकल्पों को देखना बहुत अच्छा होगा।
और विशेष रूप से मैं चाहता हूं कि इसे स्थानीय रूप से बनाई गई होस्ट निर्देशिकाओं के लिए भी लागू किया जाएगा यदि यह प्रारंभ में मौजूद नहीं है।

संबंधित (कुछ हद तक) https://github.com/moby/moby/pull/28499

क्या किसी ने Moby प्रोजेक्ट पर पहले से ही कोई समस्या खोली है?

@dnephin का उत्तर काम नहीं कर रहा है। समस्या यह है कि हम कंटेनर को एक मानक उपयोगकर्ता के रूप में चला रहे हैं, chown या chmod कमांड विफल हो रहे हैं, वॉल्यूम रूट के स्वामित्व में है, एक मानक उपयोगकर्ता अनुमतियों को नहीं बदल सकता है।

@jcberthon सुझाई गई विधि कंटेनर को शुरुआती उपयोगकर्ता के रूप में रूट के साथ चलाने के लिए है और फिर USER कमांड का उपयोग chown/chmod के बाद करें ताकि यह मूल रूप से "विशेषाधिकार छोड़ना" हो।

यह ठीक है यदि आप डॉकर छवि के नियंत्रण में हैं, लेकिन यदि आप मौजूदा छवियों का उपयोग कर रहे हैं तो यह वास्तव में एक विकल्प नहीं है।

@ Dragon788 और @micheljung , मैंने अपनी समस्या हल कर ली है।

असल में असली मुद्दा यह था कि मैं अपनी डॉकरफाइल, मैंने VOLUME घोषित किया और फिर मैंने उस वॉल्यूम में फाइलों के स्वामित्व और अनुमतियों को संशोधित किया। वे परिवर्तन खो गए हैं। केवल VOLUME घोषणा को डॉकरफाइल के अंत में ले जाकर (या इसे हटाकर, जैसा कि यह वैकल्पिक है), मेरी समस्या हल हो गई है। अनुमतियाँ सही हैं।

तो गलती थी:

FROM blabla
RUN do stuff
VOLUME /vol
RUN useradd foo && chown -R foo /vol
USER foo
CMD ["blabla.sh"]

उपरोक्त उदाहरण में chown निर्माण के दौरान खो गया है क्योंकि हम इससे पहले VOLUME घोषित करते हैं। कंटेनर चलाते समय, डॉकर्ड नामित वॉल्यूम के भीतर /vol की सामग्री को VOLUME घोषणा से पहले कॉपी करता है (इसलिए रूट अनुमतियों के साथ)। इसलिए चल रही प्रक्रियाएं अनुमतियों को संशोधित या परिवर्तित नहीं कर सकती हैं, इसलिए blabla.sh स्क्रिप्ट में मजबूर करने के लिए भी काम नहीं कर सकता है।

फ़ाइल को इसमें बदलकर:

FROM blabla
RUN do stuff
RUN useradd foo && chown -R foo /vol
USER foo
VOLUME /vol
CMD ["blabla.sh"]

समस्या सुलझ गई है।

@jcberthon क्या आप कृपया साझा कर सकते हैं कि आप अपने docker-compose.yml में होस्ट सिस्टम के साथ अपना वॉल्यूम/वॉल्यूम कैसे बांधते हैं?

मैं फेडोरा पर डॉकर के साथ काम कर रहा हूं (इसलिए, SELinux सक्षम) और उपर्युक्त विधियों में से किसी ने भी मेरे लिए काम नहीं किया। आदर्श रूप से, मैं अपने कंटेनरों में एक उपयोगकर्ता (कोई रूट नहीं) के संदर्भ में एप्लिकेशन चलाना चाहता हूं, लेकिन यह वॉल्यूम समस्या उसके लिए एक अवरोधक है।

मेरे लिए काम करने वाला एकमात्र कामकाज मेरे एप्लिकेशन उपयोगकर्ता को खत्म करना और रूट उपयोगकर्ता के रूप में सबकुछ चलाना/स्वामित्व करना है।

नमस्ते @renanwilliam और @ egee-irl

मैं कई ओएस सहित उपर्युक्त समाधान का उपयोग कर रहा हूं। फेडोरा 26 और सेंटोस 7 दोनों SELinux लागू, उबंटू 16.04, 17.10 और रास्पियन 9 तीनों के साथ AppArmor सक्रिय (amd64 और armhf प्लेटफॉर्म के मिश्रण के साथ)।

इसलिए जैसा कि मैंने कहा, मैंने अब अपने डॉकरफाइल के अंत में VOLUME ... घोषणा को स्थानांतरित कर दिया है, लेकिन आप इसे पूरी तरह से हटा सकते हैं, इसकी आवश्यकता नहीं है। डॉकरफाइल (जैसे useradd -u 8002 -o foo ) में उपयोगकर्ता बनाते समय मैं आमतौर पर उपयोगकर्ता आईडी को ठीक करता हूं। तब मैं फ़ोल्डर को उचित अनुमति देने के लिए होस्ट पर उस यूआईडी का पुन: उपयोग कर सकता हूं।

तो अगला कदम मेजबान पर /vol निर्देशिका का "लटकन" बनाना है, मान लें कि यह /opt/mycontainer1/vol , इसलिए

$ sudo mkdir -p /opt/mycontainer1/vol
$ sudo chown -R 8002 /opt/mycontainer1/vol
$ sudo chmod 0750 /opt/mycontainer1/vol

फिर कंटेनर को उपयोगकर्ता फू के रूप में चलाते समय, यह /opt/mycontainer1/vol निर्देशिका में लिखने में सक्षम होगा। कुछ इस तरह:

$ sudo -u docker-adm docker run --name mycontainer1 -v /opt/mycontainer1/vol:/vol mycontainer1-img

SELinux आधारित होस्ट पर, आप वॉल्यूम के लिए :z :Z विकल्प जोड़ना चाह सकते हैं ताकि डॉकर फ़ोल्डर को उचित रूप से टैग कर सके। z और Z बीच का अंतर यह है कि लोअरकेस z वॉल्यूम को टैग करेगा ताकि संभावित रूप से इस होस्ट के सभी कंटेनरों को उस निर्देशिका तक पहुंचने के लिए SELinux द्वारा अनुमति दी जा सके (लेकिन स्पष्ट रूप से केवल अगर आप इसे किसी अन्य कंटेनर में माउंट करते हैं), जबकि अपरकेस Z इसे टैग करेगा ताकि केवल वह विशिष्ट कंटेनर निर्देशिका तक पहुंचने में सक्षम हो। तो फेडोरा पर SELinux के साथ आप कोशिश करना चाहेंगे:

$ sudo -u docker-adm docker run --name mycontainer1 -v /opt/mycontainer1/vol:/vol:Z mycontainer1-img

अपडेट करें : आप यहां मेरा रेपो देख सकते हैं https://github.com/jcberthon/unifi-docker मैं इस विधि का उपयोग कर रहा हूं और बता रहा हूं कि होस्ट को कैसे कॉन्फ़िगर करें और अपना कंटेनर कैसे चलाएं। मुझे आशा है कि यह आपकी समस्याओं को और हल करने में मदद कर सकता है।

बीटीडब्ल्यू , मैं आपको जवाब देने में लंबी देरी के लिए हूं । साल के इस अंत में मेरे पास ज्यादा खाली समय नहीं है...

तो, अधीर के लिए लंबी कहानी छोटी:

RUN mkdir /volume_data
RUN chown postgres:postgres /volume_data

वॉल्यूम निर्देशिका पहले से बनाना और chown इसे हल करता है, क्योंकि वॉल्यूम पहले से मौजूद निर्देशिका की अनुमतियों को सुरक्षित रखेगा।

यह एक खराब काम है क्योंकि यह स्पष्ट नहीं है (डॉकरफाइल में एक चाउन करना और फिर माउंट के दौरान उस स्वामित्व को विरासत में लेना)। डॉकर-कंपोज़ और डॉकर सीएलआई पर मालिक और समूह नियंत्रण को उजागर करना यूनिक्स स्टाइल कमांड के लिए कम से कम आश्चर्य का मार्ग होगा।

@villasv

एक छोटी सी युक्ति: 2 RUN ... को एक में मिला दें, इससे अतिरिक्त परतें बनने से बचा जा सकता है और यह सर्वोत्तम अभ्यास है। तो आपकी 2 पंक्तियाँ होनी चाहिए

RUN mkdir /volume_data && chown postgres:postgres /volume_data

लेकिन सावधान रहें (जैसा कि मैंने ऊपर एक टिप्पणी में उल्लेख किया है) कि आपको VOLUME ... का उपयोग करके वॉल्यूम घोषित करने (या वास्तव में वॉल्यूम घोषित नहीं करने) से पहले उपरोक्त RUN ... कमांड करने की आवश्यकता है। यदि आप वॉल्यूम घोषित करने के बाद स्वामित्व में परिवर्तन (जैसा मैंने किया) करते हैं, तो वे परिवर्तन रिकॉर्ड नहीं किए जाते हैं और खो जाते हैं।

@colbygk यह वास्तव में आसान होगा, लेकिन ऐसा नहीं है कि लिनक्स कैसे काम करता है। डॉकर विभिन्न एकल-निर्देशिका पदानुक्रम ( / और सबफ़ोल्डर) बनाने के लिए लिनक्स माउंट नेमस्पेस का उपयोग करता है, लेकिन AFAIK वर्तमान में लिनक्स माउंट नेमस्पेस में कोई उपयोगकर्ता/समूह मैपिंग या अनुमतियां ओवरराइड नहीं कर रहा है। एक कंटेनर के अंदर "माउंट" (और इसमें बाइंड-माउंट वॉल्यूम शामिल हैं) होस्ट पर एक फाइल सिस्टम पर हैं (जब तक कि आप कुछ अन्य डॉकर वॉल्यूम प्लगइन्स का उपयोग नहीं करते हैं), और यह फाइल सिस्टम लिनक्स वीएफएस परत का सम्मान कर रहा है जो सभी करता है फ़ाइल अनुमतियों की जाँच करें। मेजबान पर कुछ मैक (जैसे SELinux, AppArmor, आदि) भी हो सकते हैं जो कंटेनर के भीतर फ़ाइलों तक पहुँचने वाले कंटेनर में हस्तक्षेप कर सकते हैं। वास्तव में यदि आप chroot , तो आप इसी तरह के मुद्दों का सामना कर सकते हैं जैसे कि आप क्रोट के भीतर माउंट फ़ोल्डर्स को बांध सकते हैं, आपको यह भी समस्या है कि चेरोट पर्यावरण के भीतर चल रही प्रक्रियाओं में फाइलों तक पहुंचने के लिए गलत प्रभावी यूआईडी/जीआईडी ​​​​हो सकता है बाँध- माउंट।

कंटेनर के लिए सरल लिनक्स (और वास्तव में यूनिक्स भी) नियम लागू होते हैं। चाल आज लिनक्स नेमस्पेस की संभावनाओं और सीमाओं को देखने और समझने की है, और फिर यह स्पष्ट हो रहा है कि इस मुद्दे जैसी समस्याओं को कैसे हल किया जाए। मैंने इसे पूरी तरह से शास्त्रीय यूनिक्स कमांड का उपयोग करके हल किया।

@jcberthon आपकी विचारशील प्रतिक्रिया के लिए धन्यवाद:

मैं तर्क दूंगा कि यह एक ऐसा मुद्दा होना चाहिए जो आपके सुझाव के अनुसार प्लगइन परत में धकेल दिया जाए और इसलिए डॉकर के साथ आने वाले जेनेरिक वॉल्यूम हैंडलर प्लगइन का हिस्सा बन सकता है। ऐसा लगता है कि एक कंटेनर से ली गई छवि में परिभाषित अनिवार्य रूप से स्थिर संबंधों का पालन करने के लिए बाहरी संसाधन (किसी विशेष कंटेनर के बाहरी) को मजबूर करने के लिए मेरे जैसा बहुत ही अनजान/कंटेनर लगता है।

इस सटीक प्रकार के यूआईडी/जीआईडी ​​मैपिंग के अन्य उदाहरण हैं जो "यूनिक्स" के अन्य समान क्षेत्रों में होते हैं:

• http://man7.org/linux/man-pages/man5/nfsidmap.5.html
• http://wiki.lusre.org/UID/GID_Mapping
• https://docs.oracle.com/cd/E19120-01/open.solaris/820-2429/mapusergroupidentities/index.html
• https://github.com/zfsonlinux/zfs/issues/4177

अगर मैं गलत हूं कृपया मुझे सही; https://github.com/zfsonlinux/zfs/issues/4177 की उत्पत्ति "LXC/LXD के नेता" द्वारा लिनक्स पर ZFS से संबंधित एक मुद्दे के रूप में हुई है, जो सही ढंग से UID/GID जानकारी प्रदान नहीं कर रहा है ताकि उन लोगों की मैपिंग की अनुमति मिल सके। लगभग _सटीक_ तरीके से हम यहां चर्चा कर रहे हैं। https://github.com/zfsonlinux/zfs/issues/4177 को करीब से देखने पर ऐसा प्रतीत होता है कि zfs वॉल्यूम प्रकार वास्तव में पहले से ही नामस्थानों के बीच इस uid/gid मैपिंग का समर्थन कर सकता है, लेकिन ऐसा करने के लिए नियंत्रणों को उजागर नहीं करता है।

डॉकर का उपयोग करने वाले अधिकांश लोग देव / सीआई के लिए हैं, हम "जेनेरिक" छवियों जैसे php/nginx (धावक) या ग्रेडल/पायथन (बिल्डर) का उपयोग करते हैं, इसलिए एक अच्छा समाधान होगा:

1. छवि को ओवरराइड करने के लिए Dockerfile बनाने/संपादित करने की कोई आवश्यकता नहीं है
2. docker-compose yml फ़ाइल में सरल सिंटैक्स का उपयोग करें

चूँकि हम आसानी से किसी वॉल्यूम (X:X:OPTION_READ_WRITE) की लिखने की अनुमति तय कर सकते हैं, उसी तरह मालिक को जोड़ने के बारे में क्या?

SOURCE:TARGET:RW:OWNER

मुझे भी यही तकलीफ़ है। शायद सबसे अच्छा अभ्यास है, और मेरी विधि _not_ है:

version: '3.5'
services:
    something:
        image: someimage
        user: '1000'
        expose:
            - 8080
        volumes:
            - dev:/app

volumes:
    dev:

यह EACCES: permission denied, access '/app' कारण बनता है।

हमें यह कैसे करना चाहिए? यानी एक नया वॉल्यूम परिभाषित करें और इसे गैर-रूट उपयोगकर्ता के साथ एक्सेस करने में सक्षम हों?

नमस्ते @Redsandro

यह बेहतर होगा कि आप someimage डॉकर छवि में यूआईडी को /app लिए यूआईडी में सेट करें। या यदि आप इसे नियंत्रित नहीं कर सकते हैं, तो आपको अपनी कंपोज़ फ़ाइल में user: ... लिए UID या GID का उपयोग करना चाहिए जिसका उद्देश्य छवि के लेखक द्वारा बनाया गया था।

बेशक यदि छवि के लेखक ने यूआईडी 0 का उपयोग किया है और आप सेवा को रूट के रूप में नहीं चलाना चाहते हैं (और यह एक गैर-विशेषाधिकार वाले उपयोगकर्ता के रूप में चल सकता है), तो डॉकर छवि लेखक के लिए एक मुद्दा उठाएं।

@Redsandro से वर्कअराउंड की जाँच करें: Docker और --userns-remap, होस्ट और कंटेनर के बीच डेटा साझा करने के लिए वॉल्यूम अनुमतियों को कैसे प्रबंधित करें?

चूंकि यह डॉकर के प्रबंधन के लिए कुछ नहीं है, आप संबंधित कंटेनर शुरू होने से ठीक पहले अपने वॉल्यूम को व्यवस्थित करने के लिए एक और कंटेनर बना सकते हैं जैसे https://hub.docker.com/r/hasnat/volumes-provisioner का उपयोग करना

version: '2'
services:
  volumes-provisioner:
    image: hasnat/volumes-provisioner
    environment:
      PROVISION_DIRECTORIES: "65534:65534:0755:/var/data/prometheus/data"
    volumes:
      - "/var/data:/var/data"

  prometheus:
    image: prom/prometheus:v2.3.2
    ports:
      - "9090:9090"
    depends_on:
      - volumes-provisioner
    volumes:
      - "/var/data/prometheus/data:/prometheus/data"

मुझे समझ में नहीं आता कि डॉकर इसे ठीक क्यों नहीं कर रहा है, मैं मानता हूं कि हम इसे देव उद्देश्यों के लिए हैक कर सकते हैं, लेकिन उत्पादन में, कोई रास्ता नहीं!

आईएमएचओ पॉडमैन एक (अनपेक्षित) उपयोगकर्ता के रूप में चलाने में सक्षम है ( यहां भी देखें) और शायद इसे हल करेगा। कोई कंपोज़ सॉल्यूशन पर भी काम करता है और पॉडमैन एपीआई जानबूझकर ज्यादातर हिस्सों में डॉकर के अनुकूल है।

[पॉडमैन] हालांकि यहां कुछ लोगों की मदद कर सकता है, क्योंकि यह बड़े हिस्से में डॉकर के अनुकूल है।

पूरी तरह से सहमत हैं, दुर्भाग्य से पॉडमैन मैक पर काम नहीं करता है

पूरी तरह से सहमत हैं, दुर्भाग्य से पॉडमैन मैक पर काम नहीं करता है

मैं अब ओएस/एक्स उपयोगकर्ता नहीं हूं लेकिन मैंने अभी देखा है कि एक _experimental_ podman dmg है ।

मुझे लगता है कि निकट भविष्य में कुछ समान पारिस्थितिकी तंत्र विकसित हो सकता है क्योंकि पहले से ही पॉडमैन प्रोग्रामेटिक या यहां तक ​​​​कि पॉडमैन-कंपोज़ तक पहुंचना संभव है।

यह विशेष रूप से एक समस्या बन जाती है जब एक साझा क्लस्टर पर sudo अधिकारों के बिना उपयोगकर्ता गलती से रूट के स्वामित्व वाले कुछ फ़ोल्डर docker-compose के माध्यम से बनाते हैं और फिर वे उन फ़ोल्डरों को स्वयं भी हटा नहीं सकते हैं।

मैं भी इस मुद्दे में भाग गया। हम jpetazzo की पोस्ट में निर्देशित के रूप में docker का उपयोग करने का प्रयास कर रहे हैं।

हम इस कंटेनर को डॉकर-कंपोज़ फ़ाइल से शुरू करना चाहते हैं और डॉकर समूह के तहत कंटेनर मशीन में होस्ट मशीन से डॉकर सॉकेट को माउंट करने में सक्षम होना चाहते हैं। ऐसा इसलिए है ताकि हम कंटेनर के अंदर से डॉक चलाने के लिए रूट के अलावा किसी अन्य उपयोगकर्ता का उपयोग कर सकें।

वर्तमान में, चूंकि मैं बाइंड माउंट फ़ाइलों के स्वामित्व और अनुमति को निर्दिष्ट नहीं कर सकता, यह प्राप्त करने योग्य नहीं है।

मेरे दो सेंट यहाँ डालें:

डॉकटर-कंपोज़ "देशी" समाधान के लिए, मैंने ऐसा किया, क्योंकि अधिकांश लोगों के पास उनकी छवि पुस्तकालय में पहले से ही अल्पाइन होगा:

volumes:
  media:
services:
  mediainit:
    image: alpine
    entrypoint: /bin/sh -c "chown -v nobody:nogroup /mnt/media && chmod -v 777 /mnt/media"
    container_name: mediainit
    restart: "no"
    volumes: 
      - "media:/mnt/media"

निश्चित रूप से सबसे सुरक्षित तरीके नहीं हैं, लेकिन केवल कंटेनर जिन्हें कंटेनर को विशेषाधिकार दिए गए हैं, वे इसे देख पाएंगे, इसलिए यह एक बड़ी बात नहीं है, लेकिन आप इसे आसानी से chown user:user बना सकते हैं या यदि आपका कर्नेल समर्थन करता है तो कुछ setacl fancness कर सकते हैं। यह।

संपादित करें: ऐसा लगता है कि आपको पहले फ़ोल्डर को चामोद से पहले चॉउन करना होगा या यह कम से कम मेरे परीक्षण में 'छड़ी' नहीं है।

वॉल्यूम स्वामित्व docker-compose के नियंत्रण में नहीं है, इसलिए यह चर्चा मोबी प्रोजेक्ट रेपो के तहत होनी चाहिए।

वर्कअराउंड के लिए यहां देख रहे लोगों के लिए कुछ नोट्स:
डॉकर वॉल्यूम, जब पहली बार एक कंटेनर द्वारा उपयोग किया जाता है, तो इसकी प्रारंभिक सामग्री और कंटेनर से विरासत में मिली अनुमति प्राप्त करें। जिसका अर्थ है कि आप अपनी छवि को इस तरह कॉन्फ़िगर कर सकते हैं:

#Dockerfile
FROM alpine
RUN addgroup -S nicolas && adduser -S nicolas -G nicolas
RUN mkdir /foo && chown nicolas:nicolas /foo  
# empty, but owned by `nicolas`. Could also have some initial content
VOLUME /foo  
USER nicolas

ऐसी छवि, जब एक स्पष्ट मात्रा के बिना चलती है (जो एक यादृच्छिक आईडी के साथ उद्देश्य पर बनाई जाएगी) या एक नामित वॉल्यूम के साथ जो अभी तक मौजूद नहीं है, वॉल्यूम के लिए अनुमतियों को "प्रचारित" करेगा:

➜  docker run --rm -it -v some_new_volume:/foo myimage
/ $ ls -al /foo
total 8
drwxr-xr-x    2 nicolas  nicolas       4096 Oct 18 08:30 .
drwxr-xr-x    1 root     root          4096 Oct 18 08:30 ..

कंपोज़ फ़ाइल में घोषित वॉल्यूम का उपयोग करते समय भी यही लागू होता है:

#docker-compose.yml
version: "3"
services:
  web:
    image: myimage
    command: ls -al /foo
    volumes:
      - db-data:/foo
volumes:
    db-data:

➜  docker-compose up
Creating volume "toto_db-data" with default driver
Creating toto_web_1 ... done
Attaching to toto_web_1
web_1  | total 8
web_1  | drwxr-xr-x    2 nicolas  nicolas       4096 Oct 18 08:30 .
web_1  | drwxr-xr-x    1 root     root          4096 Oct 18 08:37 ..
toto_web_1 exited with code 0

यदि आप किसी अन्य कंटेनर द्वारा पहले से उपयोग किए जा चुके वॉल्यूम को दोबारा संलग्न करते हैं तो यह काम नहीं करेगा। वॉल्यूम के स्वामित्व को बदलना, या निर्माण के समय इसे नियंत्रित करना इंजन द्वारा, या वॉल्यूम ड्राइवरों द्वारा कुछ विशिष्ट विकल्पों के साथ लागू किया जाना है। अन्यथा आपको सुझाए गए ^ के अनुसार कुछ chown ट्रिक्स पर निर्भर रहना होगा।

उम्मीद है ये मदद करेगा।
मैं इस मुद्दे को बंद कर रहा हूं क्योंकि रचना का वॉल्यूम निर्माण पर कोई नियंत्रण नहीं है लेकिन उजागर इंजन एपीआई है।