clientaddr उन माउंट विकल्पों में से एक है जो कारण खत्म होने के बहुत बाद तक कमांड लाइन में कॉपी किए जाते हैं। यह NFSv4.0 सर्वर को बताता है कि क्लाइंट को कहाँ वापस बुलाना है। यह सर्वर नहीं चुनता, हर अनुरोध को स्रोत पते से नहीं बाँधता और ट्रैफ़िक को सुरंग में नहीं धकेलता। कई पतों वाले लैपटॉप पर, यह लागू होता है या नहीं यह तय करने के लिए तीन सवाल चाहिए।

तीन शर्तें तय करती हैं कि विकल्प मायने रखता है या नहीं

पहली सहमत माइनर संस्करण है, क्योंकि 4.1 और 4.2 कॉलबैक अलग तरह से संभालते हैं। दूसरी यह है कि सर्वर उस पते तक पहुँच सकता है या नहीं जिसकी आप घोषणा करेंगे; रूटेड सुरंग सामान्यतः इसकी अनुमति देती है और अनूदित पथ सामान्यतः नहीं। तीसरी यह है कि आप जिस विफलता का पीछा कर रहे हैं वह कॉलबैक विफलता है या नहीं।

ConditionIf yesIf no
Version is 4.0The option can matterSkip it; inspect the session instead
Server can reach the addressAdvertise itFix reachability first
Failure is a callbackDiagnose callback pathLook at mount and export

उन्हें गलत क्रम में उत्तर देना ही वह तरीका है जिससे लोग 4.2 माउंट में कॉलबैक पता जोड़ते हैं और निष्कर्ष निकालते हैं कि विकल्प खराब है।

पहले माइनर संस्करण पढ़ें

nfsstat -m

मौजूदा माउंट के लिए, यह माउंट जानकारी और फ़्लैग छापता है, जिसमें प्रभावी संस्करण vers=4.0, vers=4.1 या vers=4.2 के रूप में शामिल है। केवल “NFSv4” कहने वाला नोट उस एक विवरण को छोड़ देता है जो तय करता है कि यह विकल्प प्रासंगिक है या नहीं। शब्द नहीं, संख्या पढ़ें।

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

4.0 के लिए, ऐसा पता घोषित करें जहाँ सर्वर पहुँच सके

NFSv4.0 सर्वर को क्लाइंट की ओर वापस अलग कनेक्शन की ज़रूरत हो सकती है, उदाहरण के लिए जब वह प्रत्यायोजन वापस बुलाता है। कई इंटरफ़ेस या असामान्य रूटिंग तालिका होने पर कॉलबैक पते की स्वचालित खोज ऐसा पता चुन सकती है जिसे सर्वर उपयोग नहीं कर सकता।

mount -t nfs -o vers=4.0,clientaddr=10.8.0.6 10.8.0.1:/export /mnt/share

कोलन से पहले का पता सर्वर है और गंतव्य ही रहता है। कॉलबैक पता क्लाइंट का है, और सुरंग के सर्वर पक्ष से उस तक पहुँचा जा सकना चाहिए। लूपबैक पता सर्वर को उसी की ओर वापस भेजता है। वापसी मार्ग के बिना निजी क्लाइंट पता भी उतना ही अनुपयोगी है, भले ही क्लाइंट पर वह सही दिखे।

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

4.1 और 4.2 इस विकल्प का उपयोग नहीं करते

Linux NFSv4.1 और 4.2 कॉलबैक उन कनेक्शनों पर ले जाते हैं जो क्लाइंट ने स्थापित किए हैं, और 4.1 उस सुविधा को backchannel कहता है। वे सर्वर द्वारा घोषित पते पर नया कनेक्शन खोलने पर निर्भर नहीं हैं, इसलिए clientaddr 4.1 या 4.2 के कॉलबैक पथ को ठीक नहीं करता।

इसका अर्थ यह नहीं कि 4.1 और 4.2 में कॉलबैक समस्याएँ नहीं हैं। इसका अर्थ है कि निदान अलग है: स्थापित सत्र और उसकी backchannel स्थिति देखें, ऐसे आने वाले कॉलबैक पोर्ट को खोजने के बजाय जो कभी होना ही नहीं था। अनुपस्थित आने वाला नियम अपेक्षित स्थिति है, सुधारने योग्य दोष नहीं।

माउंट विफलता को कॉलबैक विफलता से अलग करें

पहले सुनिश्चित करें कि क्लाइंट NFS सेवा तक पहुँचता है या नहीं और सर्वर निर्यात तथा प्रमाणीकरण अनुरोध स्वीकार करता है या नहीं। उस अदला-बदली से पहले का समयबाह्य कॉलबैक पते के बारे में कुछ नहीं कहता। माउंट के अभी विफल रहते हुए एक बदलना जाँच को आगे नहीं बढ़ाता, और यह मूल त्रुटि को नए माउंट विकल्प के पीछे छिपा देता है।

केवल जब साक्ष्य विफल 4.0 कॉलबैक दिखाए तभी घोषित पता मायने रखता है, सर्वर के वापसी पथ, क्लाइंट पक्ष के श्रोता और उनके बीच के किसी भी फ़िल्टरिंग के साथ। माउंट विकल्प में संख्या बदलना उन पथों को नहीं बना सकता; यह केवल पहले से मौजूद पथ की ओर संकेत कर सकता है। लिखिए कि उन चार में से किसे आपने सत्यापित किया, क्योंकि अगली रिपोर्ट उनमें से किसी के भी बिना आएगी।

प्रारंभिक बूट का NFS रूट अपनी पूर्वशर्तों वाला अलग वातावरण है: माउंट होने से पहले initramfs को औज़ार और नेटवर्क चाहिए। लॉगिन के बाद काम करने वाला माउंट उस क्रम के बारे में कुछ साबित नहीं करता, और बूट के समय की विफलता शायद ही कभी initramfs या नेटवर्क का ज़िक्र करती है।

संबंधित लेख