सांबा शेयर अनुमति उपयोगकर्ता लेखन फ़ाइल से इनकार कर दिया लेकिन अभी भी दिखाता है


12

बहुत ही विचित्र मुद्दा ...

रिमोट पर सांबा शेयर:

[javaerpm]
    path = /u/abas/erpm/java
    force user = erpm
    guest ok = yes
    read only = no
    writeable = yes

रूट का उपयोग कर स्थानीय पर माउंट कमांड:

root@crunchbang:/mnt/abas# mount -t cifs -o username=guest,rw,exec,auto //10.0.0.2/javaerpm ./javaerpm

रूट कोई समस्या नहीं पढ़ / लिख / सकता है:

root@crunchbang:/mnt/abas# cd javaerpm
root@crunchbang:/mnt/abas/javaerpm# touch test
root@crunchbang:/mnt/abas/javaerpm# ll
total 1
-rw-r--r--  1  501 users   0 Sep 24 09:55 test
root@crunchbang:/mnt/abas/javaerpm# rm test

लेकिन अगर मैं एक नियमित उपयोगकर्ता पर स्विच करता हूं और वही काम करता हूं जो मुझे मिलता है:

shawn@crunchbang:/mnt/abas/javaerpm$ touch test
touch: cannot touch `test': Permission denied

मैं कर सकता हूँ llऔर मैं देख सकता हूँ कि इसने फ़ाइल को वैसे भी लिखा है:

shawn@crunchbang:/mnt/abas/javaerpm$ ll
total 1
-rw-r--r--  1  501 users   0 Sep 24 09:55 test

मैं भी rmकोई समस्या नहीं कर सकते हैं :

shawn@crunchbang:/mnt/abas/javaerpm$ rm test
shawn@crunchbang:/mnt/abas/javaerpm$

मैंने विभिन्न बढ़ते विकल्पों की कोशिश की है। uid=501कुछ भी नहीं बदलता है। कोशिश की, nounixलेकिन फिर यह बिल्कुल भी काम नहीं करता है और मुझे रूट या शॉन उपयोगकर्ता का उपयोग करते हुए कुछ भी नहीं दिखता है।


यह क्यू लगभग एक ही मुद्दा दिखता है: unix.stackexchange.com/questions/71896/…
SLM

बिल्कुल वैसा ही मुद्दा नहीं।
१०:४० बजे

मैंने लगभग 8-) कहा। यह टिप्पणी मुझे और अधिक निर्देशित करने के लिए निर्देशित किया गया था ताकि भविष्य के विस्तरों के लिए सामान्य थ्रेडेड क्यू और ए को एक साथ जोड़ा जा सके, लेकिन सोचा कि आप इसे देख सकते हैं।
slm

जवाबों:


7

नोट: मैं यहां केवल अनुमान लगा रहा हूं, मैं सांबा गुरु नहीं हूं।

सांबा / सीआईएफएस, कम से कम जिस तरह से आप इसे यहां उपयोग कर रहे हैं, वह सर्वर और क्लाइंट के बीच क्रेडेंशियल्स को पुन: पेश नहीं करता है। force userसर्वर पर निर्देश के कारण , सभी ऑपरेशन erpmसर्वर पर उपयोगकर्ता के रूप में किए जाते हैं । हालाँकि, क्योंकि क्लाइंट और सर्वर दोनों एक यूनिक्स प्रणाली चला रहे हैं, उन्होंने CIFS POSIX एक्सटेंशन को ऑटो-नेगेट किया । यह यूनिक्स अनुमतियों को एक बिंदु तक काम करने के लिए प्रकट करता है, लेकिन केवल जहां तक ​​सर्वर अनुमति देता है, और आप एक ऐसे मामले में भाग लेते हैं जहां यूनिक्स अनुमतियाँ दावा करती हैं और सर्वर अलग क्या अनुमति देता है।

आप देखेंगे कि सभी फाइलें यूजर आईडी 501 के रूप में दिखाई देती हैं। यह सर्वर पर उनका यूआईडी है।

जब आप किसी फ़ाइल को बनाने या निकालने का प्रयास करते हैं, तो इसके लिए निर्देशिका पर लिखने की अनुमति चाहिए। सभी पहुंच सर्वर पर एकल उपयोगकर्ता के लिए मैप की जाती है, इसलिए अनुमति erpmलिखें कि सर्वर पर उस निर्देशिका को लिखने की अनुमति है या नहीं । इसका जवाब है हाँ।

जब आप चलाते हैं touch, तो यह फ़ाइल बनाता है और फिर इसके संशोधन का समय बदलता है। किसी फ़ाइल के संशोधन समय को बदलने के लिए स्वामित्व की आवश्यकता होती है, और यह क्लाइंट फ़ाइल पर जेनेरिक फ़ाइल सिस्टम कोड द्वारा परीक्षण किया जाता है।

यदि आप चलाते हैं strace touch test, तो आप देखेंगे कि तब openकॉल (जो फ़ाइल बनाता है) सफल होता है, तब utimesकॉल (या लिनक्स पर utimensatसिस्टम कॉल) समय निर्धारित करने में विफल रहता है।

यह वास्तव में थोड़ा अजीब है क्योंकि सफल utimes होना चाहिए , क्योंकि touchइसे एक पूर्ण तर्क के साथ कहा जाता है (जिसका अर्थ है "वर्तमान समय के लिए टाइमस्टैम्प सेट करें"), और इसे किसी भी कॉलर को अनुमति दी जानी चाहिए जो फ़ाइल में लिख सकता है, और न केवल मालिक की तरह एक मनमाना टाइमस्टैम्प स्थापित करना। मुझे संदेह है कि utimensatवास्तव में एक अनुमति-आधारित जांच कर रहा है, और यह निर्धारित करते हुए कि अनुमतियाँ कहती हैं कि आप उस फ़ाइल को नहीं लिख सकते, भले ही फ़ाइल सिस्टम वास्तविक अनुमतियों की परवाह किए बिना एक लिखने के संचालन की अनुमति देगा।

CIFS POSIX एक्सटेंशन का मुख्य लाभ जब सर्वर पक्ष एक गैर-रूट उपयोगकर्ता की अनुमतियों के साथ चल रहा है, तो निष्पादन योग्य बिट, और संभवतः समूह स्वामित्व को ले जाना है। यदि आप forceuidमाउंट ऑप्शन के साथ किसी एकल क्लाइंट-साइड उपयोगकर्ता के लिए उपयोगकर्ता के स्वामित्व को मैप करते हैं तो यह कम भ्रमित हो सकता है ।


3
पूरी तरह से प्रतिक्रिया के लिए बहुत बहुत धन्यवाद। मैंने अंततः कोशिश की username=guest,defaults,nopermऔर इस मुद्दे को पूरी तरह से ठीक कर दिया। मुझे नहीं पता कि इस पर स्वीकार करने का क्या जवाब है क्योंकि username=guest,defaults,nopermशायद सबसे अच्छा जवाब नहीं है और मेरे पास आपके जवाब को आज़माने के लिए अधिक समय नहीं है। फिर से धन्यवाद!
१६:३imp

@shrimpwagon आपके अपडेट के लिए धन्यवाद। इससे मेरी समस्या हल हो गई ... मैं लंबे समय से चूक और डोपिंग में पाइप करने के बारे में भूल गया था जब बढ़ते थे।
मैथ्यू
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.