ক্লায়েন্টের সংযোগ বিচ্ছিন্ন হওয়ার পরে সাম্বাকে কীভাবে একটি ফাইল লক রাখা থেকে আটকাতে হবে?

Question

এখানে আমার একটি সাম্বা সার্ভার রয়েছে (দেবিয়ান 5.0) টি উইন্ডোজ এক্সপি প্রোফাইল হোস্ট করার জন্য কনফিগার করা হয়েছে।

ক্লায়েন্টরা এই সার্ভারের সাথে সংযোগ স্থাপন করে এবং তাদের প্রোফাইলে সাম্বা শেয়ারে সরাসরি কাজ করে (প্রোফাইল স্থানীয়ভাবে অনুলিপি করা হয় না)।

এখন থেকে এবং পরে, কোনও ক্লায়েন্ট সঠিকভাবে শাটডাউন না করতে পারে এবং এইভাবে উইন্ডোজ ফাইল লকগুলি মুক্ত করে না। সাম্বা লকিং টেবিলটির দিকে তাকানোর সময় আমরা দেখতে পাই যে ক্লায়েন্টটি আর সংযুক্ত না থাকলেও অনেকগুলি ফাইল এখনও লক করা আছে are আমাদের ক্ষেত্রে, এটি মজিলা থান্ডারবার্ড এবং ফায়ারফক্সের দ্বারা নির্মিত লকফিলগুলির সাথে ঘটেছিল বলে মনে হচ্ছে। এখানে সাম্বা লকিং টেবিলের একটি উদাহরণ রয়েছে:

# smbstatus -L | grep DENY_ALL | head -n5
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
15494        10345      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user1   app.profile/user1.thunderbird/parent.lock   Mon Nov 22 07:12:45 2010
18040        10454      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user2   app.profile/user2.thunderbird/parent.lock   Mon Nov 22 11:20:45 2010
26466        10056      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user3   app.profile/user3.firefox/parent.lock   Mon Nov 22 08:48:23 2010

আমরা দেখতে পাচ্ছি যে ফাইলগুলি উইন্ডোজ দ্বারা খোলা হয়েছিল এবং একটি DENY_ALL লক চাপিয়েছে।

এখন যখন কোনও ক্লায়েন্ট এই ভাগটি পুনরায় সংযুক্ত করে এবং সেই ফাইলগুলি খোলার চেষ্টা করে, সাম্বা বলে যে তারা লক হয়ে গেছে এবং অ্যাক্সেস অস্বীকার করে।

এই পরিস্থিতিটি ঘিরে কাজ করার কোনও উপায় আছে বা আমি কিছু মিস করছি?

সম্পাদনা: আমরা সাম্বা সার্ভারে ফাইল লকগুলি অক্ষম করা এড়াতে চাই কারণ এগুলি সক্ষম করার উপযুক্ত কারণ রয়েছে।

Answer 1

নীচের পদক্ষেপগুলি আমাকে বেশ কয়েকবার এই সঠিক সমস্যাটি সমাধান করতে সহায়তা করেছে:

1. সামা সার্ভারে লগইন করুন।
2. একটি "এসএমএসস্ট্যাটাস" চালান।
3. আউটপুট তৃতীয় বিভাগে ফাইলটিতে লক রয়েছে এমন প্রক্রিয়াটির পিডটি সন্ধান করুন।
4. এটি smbstatus আউটপুটটির প্রথম এবং দ্বিতীয় বিভাগে প্রত্যাশিত ব্যবহারকারীর এবং হোস্টনামের সাথে মেলে তা যাচাই করুন।
5. "পিএস-শেফ" চালান এবং দেখুন যে পিডের সাথে এসএমবিডি কতক্ষণ চলছে।
6. কম্পিউটারটি শেষবার রিবুট করার আগে থেকে যদি এটি চলতে থাকে তবে এটি এসএমবিডি বামে। কেবলমাত্র এসএমবিডকে মেরে ফেলুন। (এবং নিশ্চিত করুন যে আপনি সঠিকটি পেয়েছেন - এটির প্যারেন্ট পিডটি 1 এর সমান নয় should

Comments

এছাড়াও, আপনি দেখতে পাবেন যে কিছু এসএমডি পিডগুলি কয়েক ঘন্টা ধরে চলছে এবং তারা যে ফাইলগুলি লক করেছে সেগুলি আপনার প্রয়োজনীয় need উপরের হিসাবে, কেবল এই প্রক্রিয়াগুলি হত্যা করুন এবং আপনার ভাল হওয়া উচিত। যদি আপনি অজান্তে মূল এসএমবিডি প্রক্রিয়াটি হত্যা করেন তবে আপনি এই আদেশটি দিয়ে এটি পুনরায় আরম্ভ করতে পারেন: sudo /etc/init.d/smbd পুনঃসূচনা

— সক্রেরোস

Answer 2

একটু দেখো:

reset on zero vc = yes / no

এবং দেখুন এটি আপনার সমস্যার সমাধান করবে কিনা।

থেকে smb.confমানুষ পৃষ্ঠা:

এই বুলিয়ান বিকল্পটি নিয়ন্ত্রণ করে যে ইনকামিং সেশন সেটআপ একই আইপি থেকে আসা অন্যান্য সংযোগগুলিকে মেরে ফেলবে কিনা। এটি ডিফল্ট উইন্ডোজ 2003 আচরণের সাথে মেলে। হ্যাঁ এই প্যারামিটারটি সেট করা প্রয়োজনীয় হয়ে পড়ে যখন আপনার একটি ফ্ল্যাশ নেটওয়ার্ক থাকে এবং উইন্ডোজ পুনরায় সংযোগ স্থাপনের সিদ্ধান্ত নেয় যখন পুরানো সংযোগটিতে এখনও ভাগ করার মোডের ফাইল রয়েছে। এই ফাইলগুলি নতুন সংযোগের মাধ্যমে অ্যাক্সেসযোগ্য become ক্লায়েন্টটি নতুন সংযোগে একটি শূন্য ভিসি প্রেরণ করে এবং উইন্ডোজ 2003 একই আইপি থেকে আসা সমস্ত অন্যান্য সংযোগকে হত্যা করে। এই ভাবে লক করা ফাইলগুলি আবার অ্যাক্সেসযোগ্য। দয়া করে সচেতন থাকুন যে এই বিকল্পটি সক্ষম করা কোনও মাস্ক্রেডিং রাউটারের পিছনে সংযোগকে হত্যা করবে।

সম্পাদনা :
আমি কেবলমাত্র অন্য একটি সম্ভাব্য সমাধান নিয়ে ভাবলাম। প্রশ্নের শেয়ারে আপনি এরকম কিছু করতে পারেন could

veto oplock files = /*.lock/

এটি কেবল। লক ফাইলগুলিতে ওপলকগুলি রোধ করবে।

Answer 3

সাম্বার কিছু অতি চালাক লোক এই বিকল্পটি সরিয়ে নেওয়ার সিদ্ধান্ত নিয়েছে এবং এর কোনও প্রতিস্থাপন নেই।

এতক্ষণে এসএমবি তুলনামূলক পক্ষে, কারণ এটি সত্যই ডিফল্ট জিন আচরণ।

কোনও ব্যবহারকারী লিনাক্স কমান্ড লাইনে দক্ষ না হলে এবং কীভাবে ফাইল / প্রসেস খুলতে পারবেন, এটিকে সাফ করার জন্য আপনাকে এসএমবিডি বা সার্ভার নিজেই পুনরায় চালু করতে হবে।

আশ্চর্যরূপে সম্পন্ন, সাম্বা.অর্গ।

Comments

আপনি কি এই জন্য একটি প্রশংসাপত্র আছে?

— BE77Y

সেখানে যাওয়ার জন্য আপনাকে কয়েকজনকে দেখতে হবে, তবে: list.samba.org/archive/samba-technical/2011- জুলাই / 078621.html (চিন্তার প্রক্রিয়া এবং অধ্যায়গুলি এটি সরিয়ে না দেওয়ার জন্য অনুরোধ করুন) তালিকাগুলি দেখান .samba.org / সংরক্ষণাগার / সাম্বা-প্রযুক্তিগত / ২০০৮-অক্টোবর /… (দেখায় যে প্যারামিটারটি 4.0 এ সরানো হয়েছে)

— মাইকেল

2019 হিসাবে, ডিবিয়ান 9 - সাম্বা 4.5.12 তে, reset on zero vcবিকল্পটি ম্যানুয়ালটিতে এখনও তালিকাভুক্ত রয়েছে এবং এর দ্বারা প্রদর্শিত হবে testparm। সুতরাং হয় এটি ফিরে এসেছে, বা এটি সত্যিই সরানো হয়নি।

— mivk

Answer 4

আমি একই ধরণের সমস্যায় পড়ছিলাম, একটি ক্লায়েন্ট একটি বড় ফাইল অনুলিপি করার সময় ক্র্যাশ হয়ে গেছে এবং ফাইলটি রিবুটের পরে লক হয়ে গেছে। ভাগ্যক্রমে এটি প্রায়শই ঘটে না, তবে এটি সাম্বা প্রক্রিয়াটি হত্যার জন্য যথেষ্ট বিরক্তিকর। reset on zero vcএটি কেবল সমাধান বলে মনে হয়েছে, তবে এটি সম্ভবত সমবা 4 থেকে অপসারণ করা হয়েছে, যদিও ফেডোরার ২ 27. Version. Version সংস্করণ (২ 27) এখনও রয়েছে (সম্ভবত আরএইচ দ্বারা প্যাচড)। ম্যান পেজটি এখন যেমন বলেছে এটি এটি তেমন কোনও উপকারে আসবে না, এটি কেবল এসএমবি 1 এর সাথে কাজ করে (যা আর ব্যবহার করা উচিত নয়) এবং এসএমবি 2 এবং এসএমবি 3 সংযোগে কিছুই করে না, এটি হ্যান্ডেল করার একমাত্র উপায় উল্লেখ করা হয়েছে থ্রেড মিশেল দ্বারা সংযুক্ত । অপসারণের পিছনে যুক্তি এবং এর মধ্যে কী খারাপ তা আমি জানি নাreset on zero vc, আমি হ্যাকের মতো আরও এই উদ্দেশ্যে টিসিপি টাইমআউট ব্যবহার করার বিষয়টি বিবেচনা করব। যাইহোক কিছু যুক্তিসঙ্গত উদাহরণ হতে পারে

socket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPIDLE=30 TCP_KEEPCNT=3 TCP_KEEPINTVL=3

এটি সর্বশেষ যোগাযোগের পরে সংযোগটি প্রায় 40 সেকেন্ড (30 + 3 * 3) নষ্ট করে দেবে, যা সাধারণত ক্র্যাশ এবং রিবুট করার জন্য যথেষ্ট পরিমাণে বেশি (সার্ভারের টিসিপি স্ট্যাকটি ক্লায়েন্টের সাথে সংযোগ বন্ধ করার জন্য যথেষ্ট স্মার্ট বলে মনে হয়) রিবুটের পরে এর রক্ষণশীল প্যাকেটগুলি প্রত্যাখ্যান করে)।

মনে রাখবেন যে এটি আপনার নেটওয়ার্কের বোঝা বৃদ্ধি করে, তবে আমি সন্দেহ করি যে এটি অনেক ক্লায়েন্টের সাথে এমনকি এটি লক্ষণীয়।

Comments

আপনি কি অবগত আছেন যে এটি উদ্ভট উইন্ডোজ 10 ক্লায়েন্ট "কেউ নোগ্রুপ" জম্বি থ্রেড সমস্যার সাথে সহায়তা করে কিনা? বেশ কয়েকটি সাইটে আমার উইন্ডোজ 10 ক্লায়েন্টদের অনেকেই শত শত (মাঝেমধ্যে কয়েক হাজার) জম্বি থ্রেড ছেড়ে যেতে শুরু করেছেন যা তাদের হ্যান্ডলারের প্রক্রিয়াটি নিহত / অবসর না হওয়া পর্যন্ত "নোংগ্রুপ" হিসাবে অর্পিত হয়। সাধারণত সেট করা deadtime = 10বা এটি এটিকে সাফ করে দেবে, তবে এসএমবি 3_11 সংযোগে ফাইল লকগুলি চিরকালের জন্য কার্যকর হয় না, কারণ পিআইডি-র জন্য ফাইললকগুলি বিদ্যমান থাকার সময়সীমা পরীক্ষা করা হবে না। চরম হতাশাজনক।

— zxq9

আপনার বর্ণিত সমস্যাটি আমি কখনও শুনি নি বা অভিজ্ঞতাও পাইনি। deadtimeআপনার ক্লায়েন্টদের যদি ফাইলগুলি খোলা থাকে তবে কিছুই করে না, সুতরাং প্রশ্নটি হ'ল তারা কোন ফাইলটি খোলা রাখবে। তবে এটি সম্ভবত এখানে ভিন্ন আলোচনার চেয়ে সম্পূর্ণ ভিন্ন ইস্যু, সুতরাং আপনার এটির জন্য একটি নতুন প্রশ্ন খোলা উচিত। আমার socket optionsপরামর্শটি কেবলমাত্র এমন সংযোগগুলিতে সহায়তা করে যা সঠিকভাবে বন্ধ নয় (কারণ ক্লায়েন্ট ক্র্যাশ করে, একটি নেটওয়ার্ক আউটেজ ইত্যাদি) তবে আপনার ডাব্লুএক্স ক্লায়েন্টরা কেবলমাত্র কোনও পদক্ষেপ ছাড়াই বা কোনও ধরণের বেনামি অধিবেশন ব্যবহার না করে সার্ভারের সাথে সংযুক্ত থাকলে (যা nobody.nogroupপ্রস্তাব দেয়) )।

— জাকব

এই সমস্যাটি সম্পর্কে একটি প্রশ্ন রয়েছে বলে মনে হয় , তবে আসল সমাধান ছাড়াই। মনে হচ্ছে এটি সাম্বার সমস্যা হতে পারে যা আরও সাম্প্রতিক সংস্করণে স্থির করা যেতে পারে।

— জাকব

মেলিং তালিকায় এর বেশ কয়েকটি উল্লেখ রয়েছে, কোথাও প্রকৃত সমাধান উপস্থাপন করা হয়নি এবং আমি চেষ্টা করেছি এমন কোনও সংস্করণ (প্রতিটি বর্তমান শাখা তবে 4.9) সমস্যাটি সমাধান করে না। এটি কেবল উইন্ডোজ 10 ক্লায়েন্টের সাথে রয়েছে। কেউ নেই: নোগ্রুপ জিনিসটি বিভ্রান্ত করছে, যেহেতু বিশ্বব্যাপী অতিথি অক্ষম হয়ে গেছে, কোনও ভাগই তাদের গ্রহণ করে না, এবং কারও প্রবেশের পিআইডি সর্বদা বৈধ ব্যবহারকারীর নাম সহ একক বৈধ এন্ট্রি হিসাবে সমান হয়। সুতরাং আপনি 12345 someuser somegroup...একটি এন্ট্রিতে দেখুন, তারপরে 800 12345 nobody nogroup ...টি এন্ট্রি, তবে কেবলমাত্র কয়েকটি মুখ্য ফাইল লক (800 নয়)। খুবই অদ্ভুত. আমার ক্লায়েন্ট সাইটগুলিতে এখন 3 টি প্রভাবিত করে।

— zxq9

এটি কেবলমাত্র উচ্চ-ক্রিয়াকলাপের সাইটগুলিতে সংস্থান হিসাবে সীমাবদ্ধ হয়ে যায়, এ কারণেই আমি মনে করি এটি এত কম মনোযোগ পেয়েছে। বেশিরভাগ সময় কোনও সমস্যা হয় না, তাই লোকেরা কেবল এটি লক্ষ্য করে না এবং ক্লায়েন্টরা যখনই তাদের সংযোগটি বন্ধ করে দেয় তখনই এটি সরে যায়।

— zxq9

Answer 5

আপনি নিম্নলিখিত শেয়ারের সাথে প্রতি শেয়ারের ভিত্তিতে ওপলকগুলি অক্ষম করতে পারেন:

[acctdata]
oplocks = False
level2 oplocks = False

ডিফল্ট ওপলক ধরণটি লেভেল 1। শ্রেনী 2 অপলকগুলি smb.conf ফাইলে প্রতি শেয়ারের ভিত্তিতে সক্ষম করা হয়েছে। পর্যায়ক্রমে, আপনি ভাগের মধ্যে প্রতি ফাইলের ভিত্তিতে ওপলকগুলি অক্ষম করতে পারেন:

veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

যদি আপনি ওপলকে সমস্যায় পড়ে থাকেন, যেমন সাম্বার লগ এন্ট্রি থেকে বোঝা যাচ্ছে, আপনি এটি নিরাপদে খেলতে এবং ওপলকগুলি এবং লেভেল 2 ওপলকগুলি অক্ষম করতে চাইতে পারেন।

কার্নেল ওপলকসকে অক্ষম করা কার্নেল ওপলকগুলি একটি এসএমবি কোডফ প্যারামিটার যা সাম্বা (যদি ইউএনআইএক্স কার্নেলের একটি উইন্ডোজ ক্লায়েন্টকে একটি ওপলক ব্রেক প্রেরণ করার ক্ষমতা রাখে) জানায় যখন একটি ইউএনএক্স প্রক্রিয়া ক্যাশে হওয়া ফাইলটি খোলার চেষ্টা করছে। এই পরামিতিটি সাম্বা সার্ভারে ইউনিক্স এবং উইন্ডোজের মধ্যে থাকা ওপলকগুলি সহ ফাইলগুলি ভাগ করে নেওয়ার ঠিকানা দেয়: ইউএনআইএক্স প্রক্রিয়া উইন্ডোজ ক্লায়েন্টের দ্বারা অপলক করা (ক্যাশেড) ফাইলটি খুলতে পারে এবং এসএমডি প্রক্রিয়াটি একটি ওপলক ব্রেক প্রেরণ করে না, যা ফাইলটিকে উন্মুক্ত করে দেয় ডেটা দুর্নীতির ঝুঁকি। যদি ইউনিক্স কার্নেলের একটি ওপলোক ব্রেক প্রেরণের ক্ষমতা থাকে তবে কার্নেল ওপলক্স প্যারামিটার সাম্বাকে ওপলোক ব্রেক প্রেরণ করতে সক্ষম করে। কার্নেল ওপলকগুলি smb.conf ফাইলে প্রতি সার্ভারের ভিত্তিতে সক্ষম করা হয়েছে।

kernel oplocks = yes

ডিফল্ট হয় না।

সূত্র