שיתוף SMB ב-Mac דרך VPN: קודם להתחבר, אחר כך לבדוק כתיבה

Finder מעלה את השיתוף אך מסרב לשמור? הפרידו בין נתיב ה-VPN, חשבון ה-SMB והרשאת השרת לפני שתשנו הגדרה כלשהי.

אם Finder מעלה את השיתוף דרך ה-VPN ואז מסרב לשמור קובץ, המנהרה כבר עושה את שלה והמחלוקת היא על זהות והרשאות בשרת הקבצים. אם ההעלאה כלל לא מופיעה, שום דבר מעבר לנקודה הזו לא נבדק. שני המקרים מסתיימים בתיבת דו-שיח דומה ב-macOS, ולכן אנשים בונים מחדש פרופילי VPN בגלל תקלה שה-VPN לא יכול ליצור. אני מתחיל בקביעה מדויקת היכן החיבור נעצר, ורק אחר כך בודק כתיבה עם קובץ חד-פעמי במקום המסמך שבאתי לערוך.

שלושה תנאים קובעים היכן להסתכל

נדרשים שלושה מענים לפני שנוגעים בהגדרה: האם השם נפתר לכתובת פרטית שהמנהרה מנתבת, האם שירות ה-SMB מקבל את החשבון המדויק שסיפקתם, והאם לחשבון הזה יש הרשאות כתיבה בדיוק על השיתוף, התיקייה והפעולה האלה. כל אחד נכשל במקום אחר, ורק הראשון שייך לבעל ה-VPN.

What you seeWhat it establishesWho fixes it
Name does not resolve, or resolves outside the tunnelThe path was never builtVPN or DNS administrator
Name resolves, port 445 times outRoute, firewall or overlapping address spaceVPN and network owners
Server answers, the sign-in is rejectedThe file-service account, not the VPN loginFile-server owner
Share mounts, writing is refusedShare policy or directory rightsFile-server owner

הטבלה מצדיקה את מקומה משום שכניסה ל-Mac, כניסה ל-VPN וחשבון SMB הם שלוש זהויות נפרדות. שינוי סיסמת ה-VPN לעולם לא יפתח שיתוף שמסרב למשתמש הרשום, ולקוח שמדווח על חיבור אינו אומר דבר על השרת שאליו אתם מכוונים.

התחברו לפי כתובת, לא לפי גלישה

שיתוף מרוחק יכול להיות נגיש לחלוטין ועדיין בלתי נראה ברשימת הרשת של Finder. גילוי ברשת משרדית נשען על שמות שידור ו-multicast, ורוב ה-VPN-ים אינם מעבירים את התעבורה הזו דרך המנהרה, ולכן תצוגת רשת ריקה אינה הוכחה לקישור שבור.

  1. הפעילו את ה-VPN המיועד דרך הלקוח הרגיל שלו והשלימו את האימות.

  2. ב-Finder בחרו עבור ואז התחבר לשרת, או הקישו Command-K.

  3. הקלידו את הכתובת שסופקה. בדוגמה הזו היא smb://files.corp.example/team, שם להמחשה ולא שירות ציבורי. אם יש לכם רק את שם השרת, התחברו אליו ובחרו את השיתוף המורשה מהרשימה שהוא מחזיר.

  4. בחרו משתמש רשום והזינו את חשבון שירות הקבצים, לא את חשבון ה-Mac ולא את חשבון ה-VPN. אורח נכון רק כשהבעלים אומר כך.

  5. פתחו את השיתוף ועשו את המשימה האחת שבאתם בשבילה. רשימת תיקייה מוכיחה את ההעלאה ולא יותר.

המדריך של Apple להתחברות לשרת מתעד את זרימת העבודה הזו ב-Finder ואת הכניסה לשירות שמאחוריה. שמרו את הכתובת כמועדפת כדי שהחיבור הבא יהיה ניתן לחזרה, וזכרו ששינוי שם הרשומה משנה את התווית, לא את היעד.

קראו את השלב שבו זה נעצר

לפני שמשנים משהו, רשמו איזה שלב נכשל, עם אותם שמות שהקלדתם ב-Finder. התחילו בפתרון השם: dscacheutil -q host -a name files.corp.example מדפיס את הכתובת שבה ישתמש macOS, ו-netstat -rn מראה אם לכתובת הזו יש נתיב דרך ממשק המנהרה או דרך שער הבית שלכם.

אחר כך נגישות. nc -vz files.corp.example 445 אומר אם יציאת ה-SMB עונה בכלל; אם פתרון השם עובד ו-445 מגיע לפסק זמן, אתם בתחום הניתוב, חומת האש או כתובות חופפות ושום שינוי בהרשאות השיתוף לא יעזור. אם היציאה עונה, שאלו את השרת מה הוא מציע לחשבון הזה: smbutil view //[email protected] מפרט שיתופים, ו-smbutil statshares -a מדווח על הניב שנקבע ועל מצב החתימה של ההפעלה שהועלתה, מה שאומר לכם אם ההעלאה שאתם בודקים היא זו שאתם חושבים.

זהות ראויה לבדיקה נפרדת, כי זה השלב שאנשים מדלגים עליו. העלאה יכולה להתקיים כאורח או כחשבון שמור ישן בזמן שאתם מניחים שאתם המשתמש הרשום, ואז כל בדיקת כתיבה מודדת את החשבון הלא נכון.

להרשאת כתיבה יש יותר משער אחד

שתי שכבות יכולות לומר לא בצד השרת ושתיהן נראות זהות מה-Mac. שיתוף יכול להיות מיוצא לקריאה בלבד בזמן שהתיקייה שמתחתיו ניתנת לכתיבה, ושיתוף שניתן לכתיבה אינו יכול לעקוף ACL של מערכת קבצים שמסרב לחשבון שלכם; תת-תיקייה יכולה גם לשאת מדיניות משלה. בשרתי Windows הרשאת השיתוף והרשאות NTFS נפרדות, והזכות האפקטיבית היא המגבילה מבין השתיים.

אז החליטו מה בדיוק נדחה: יצירת קובץ, עריכת קיים, יצירת תיקייה, שינוי שם או מחיקה. אלה אינם הרשאה אחת, ותיקייה שבה הרישום עובד יכולה לדחות את כולם. העלאה שעובדת אינה הרשאה.

אם אתם חושדים בזהות הלא נכונה, הוציאו את השיתוף, מחקו את הרשומה הישנה בגישה למחזיק מפתחות והתחברו שוב עם החשבון הרשום. Finder ישמח לעשות שימוש חוזר בהפעלה שמורה ויותיר אתכם מודדים הרשאות למשתמש שהשרת לא רואה בכם.

בדקו כתיבה בלי לגעת במסמכים אמיתיים

בהסכמת הבעלים, צרו קובץ קטן אחד בשם חדש בתיקייה שנכשלת: touch /Volumes/team/qa-write-test.txt כשהשיתוף מותקן שם, או פשוט שמור בשם אחר עם שם חדש מהיישום. לעולם אל תדרסו מסמך כדי לבדוק גישה, ושמרו את טקסט השגיאה המדויק במקום לנסח אותו מחדש, כי ה-VPN לא יעתיק אותו.

אחר כך מסרו לבעלים את הפעולה שניסיתם ולא תלונה כללית. הם יכולים לבדוק את מדיניות השיתוף, את חברות החשבון בקבוצות ואת ההרשאות על אותה תיקייה, ולומר לכם איזו שכבה דחתה אתכם. אם ההודעה מזכירה קיבולת, קובץ נעול או התנגשות שמות, זו בעיה אחרת והיא ראויה לבדיקה משלה.

אמתו את התיקון ואז הוציאו לפי הסדר

אחרי שהבעלים שינה משהו, חזרו על אותה כתיבה קטנה ואשרו שהקובץ נראה לשרת וניתן להסרה לאחר מכן. העתקה שמתחילה ואז נתקעת היא שאלת תפוקה, לא שאלת הרשאה; סירוב שמגיע מיד הוא שאלת הרשאה.

לפני שאתם מנתקים את ה-VPN, בטלו את התקנת השיתוף וסגרו מסמכים פתוחים. הוצאה אחרי שהמנהרה נעלמה משאירה את Finder והיישומים שלכם ממתינים לנתיב מת. שמרו את SMB בתוך הרשת הפרטית, אל תכבו את חומת האש כדי לבדוק תיאוריה, ואל תפתחו תיקייה לכולם כדרך עקיפה. לכרטיס, כללו את הכתובת, שם החשבון, הפעולה שנכשלה, הטקסט המדויק של ההודעה והשעה, והשאירו בחוץ סיסמאות וקובצי פרופיל.

  • הכתובת נפתרת לכתובת פרטית שמנותבת דרך המנהרה.
  • יציאה 445 עונה ו-smbutil view מפרט את השיתוף המיועד עבור החשבון המיועד.
  • הכתיבה שהייתם צריכים מוכחת בקובץ חדש, לא במסמך קיים.

מאמרים קשורים