SMB share sa Mac gamit ang VPN: kumonekta muna, saka subukan ang pagsulat
Nag-mount ang Finder ng share pero tumatangging mag-save? Paghiwalayin ang VPN path, SMB account at permiso ng server bago baguhin ang anumang setting.
Kung ini-mount ng Finder ang share sa VPN at pagkatapos ay tumangging mag-save ng file, ginagawa na ng tunnel ang trabaho nito at ang hindi pagkakasundo ay tungkol sa pagkakakilanlan at mga karapatan sa file server. Kung hindi lumilitaw ang mount, wala pang nasubukan pagkalampas sa puntong iyon. Pareho ang hantungan ng dalawang kaso sa katulad na dialog sa macOS, kaya muling itinatayo ng mga tao ang mga profile ng VPN dahil sa sira na hindi kayang likhain ng VPN. Sinisimulan ko sa pagtukoy nang eksakto kung saan humihinto ang koneksyon, at doon lang sumusubok ng pagsulat gamit ang itatapong file kaysa sa dokumentong pinunta ko para i-edit.
Tatlong kundisyon ang nagtatakda kung saan titingin
Kailangan mo ng tatlong sagot bago hawakan ang isang setting: niresolba ba ang pangalan sa pribadong address na dinadaanan ng tunnel, tinatanggap ba ng serbisyo ng SMB ang eksaktong account na ibinigay mo, at may karapatan ka bang sumulat sa eksaktong share, folder at operasyon na iyon. Bawat isa ay nabigo sa magkaibang lugar, at ang una lang ang pag-aari ng may-ari ng VPN.
| What you see | What it establishes | Who fixes it |
|---|---|---|
| Name does not resolve, or resolves outside the tunnel | The path was never built | VPN or DNS administrator |
| Name resolves, port 445 times out | Route, firewall or overlapping address space | VPN and network owners |
| Server answers, the sign-in is rejected | The file-service account, not the VPN login | File-server owner |
| Share mounts, writing is refused | Share policy or directory rights | File-server owner |
May saysay ang talahanayan dahil ang pag-login sa Mac, pag-login sa VPN at SMB account ay tatlong magkahiwalay na pagkakakilanlan. Ang pagpapalit ng password ng VPN ay hindi kailanman nagbubukas ng share na tumatanggi sa rehistradong user, at ang client na nag-uulat ng koneksyon ay walang sinasabi tungkol sa server na pinupuntirya mo.
Kumonekta sa address, hindi sa pag-browse
Ang malayong share ay maaaring ganap na maabot habang nananatiling hindi nakikita sa Network list ng Finder. Ang pagtuklas sa LAN ng opisina ay umaasa sa broadcast at multicast na pangalan, at karamihan sa VPN ay hindi nagdadala ng trapikong iyon sa tunnel, kaya ang walang laman na tanawin ng Network ay hindi patunay ng putol na link.
Ilunsad ang nilalayong VPN gamit ang karaniwang client nito at tapusin ang authentication.
Sa Finder piliin ang Go, pagkatapos ay Connect to Server, o pindutin ang Command-K.
I-type ang ibinigay na address. Sa halimbawang ito ito ay
smb://files.corp.example/team, isang pantulong na pangalan at hindi pampublikong serbisyo. Kung pangalan lang ng server ang mayroon ka, kumonekta rito at piliin ang awtorisadong share mula sa listahang ibinabalik nito.Piliin ang Registered User at ilagay ang account ng file service, hindi ang iyong Mac account at hindi ang VPN account. Tama lang ang Guest kapag sinabi ng may-ari.
Buksan ang share at gawin ang isang gawaing pinuntahan mo. Ang listahan ng folder ay nagpapatunay ng mount at wala nang iba.
Ang gabay ng Apple sa pagkonekta sa server ay nagdodokumento ng daloy na ito sa Finder at ng pag-login sa serbisyo sa likod nito. I-save ang address bilang paborito upang maulit ang susunod na koneksyon, at tandaan na ang pagpapalit ng pangalan ng entry ay nagbabago ng label, hindi ng target.
Basahin ang yugto kung saan ito humihinto
Bago magbago ng anuman, itala kung aling yugto ang nabigo, gamit ang parehong pangalan na tina-type mo sa Finder. Magsimula sa pagresolba ng pangalan: dscacheutil -q host -a name files.corp.example ipinapakita ang address na gagamitin ng macOS, at netstat -rn ipinapakita kung ang address na iyon ay may ruta sa interface ng tunnel o sa gateway ng bahay mo.
Susunod ang maabot. nc -vz files.corp.example 445 sinasabi kung sumasagot man lang ang port ng SMB; kung gumagana ang resolusyon at nag-timeout ang 445, nasa teritoryo ka ng routing, firewall o magkapatong na address at walang pagbabago sa permiso ng share ang makakatulong. Kung sumasagot ang port, tanungin ang server kung ano ang iniaalok nito sa account na iyon: smbutil view //[email protected] naglilista ng mga share, at smbutil statshares -a nag-uulat ng napagkasunduang dialect at estado ng pirma ng naka-mount na session, na nagsasabi kung ang mount na sinusubukan mo ay ang iniisip mo.
Ang pagkakakilanlan ay karapat-dapat sa sariling pagsusuri, dahil iyon ang hakbang na nilalaktawan ng mga tao. Ang mount ay maaaring buhay bilang guest o bilang lumang naka-save na account habang iniisip mong rehistradong user ka, at pagkatapos ay sinusukat ng bawat pagsubok ng pagsulat ang maling account.
Ang access sa pagsulat ay may higit sa isang pintuan
Dalawang layer ang maaaring tumanggi sa panig ng server at pareho silang magkamukha mula sa Mac. Ang share ay maaaring i-export na read-only habang ang folder sa ilalim nito ay maisusulat, at ang maisusulat na share ay hindi maaaring laktawan ang ACL ng file system na tumatanggi sa account mo; ang subfolder ay maaaring may sariling patakaran. Sa mga server ng Windows, hiwalay ang permiso ng share at ang mga permiso ng NTFS, at ang epektibong karapatan ay ang mas mahigpit sa dalawa.
Kaya magpasya kung ano talaga ang tinatanggihan: paggawa ng file, pag-edit ng umiiral, paggawa ng folder, pagpapalit ng pangalan o pagbura. Hindi ito isang permiso, at ang folder kung saan gumagana ang listahan ay maaaring tumanggi sa lahat ng iyon. Ang gumaganang mount ay hindi pahintulot.
Kung pinaghihinalaan mo ang maling pagkakakilanlan, ilabas ang share, burahin ang lumang entry sa Keychain Access at kumonekta muli gamit ang rehistradong account. Masayang gagamitin muli ng Finder ang naka-save na session at iiwan kang sinusukat ang mga permiso para sa user na hindi itinuturing ng server na ikaw.
Subukan ang pagsulat nang hindi hinahawakan ang totoong dokumento
Sa pahintulot ng may-ari, gumawa ng isang maliit na file sa ilalim ng bagong pangalan sa folder na nabigo: touch /Volumes/team/qa-write-test.txt kapag naka-mount doon ang share, o simpleng Save As gamit ang bagong pangalan mula sa app. Huwag kailanman i-overwrite ang dokumento para subukan ang access, at itago ang eksaktong teksto ng error sa halip na i-paraphrase ito, dahil hindi ito kokopyahin ng VPN.
Pagkatapos ibigay sa may-ari ang operasyong sinubukan mo at hindi ang pangkalahatang reklamo. Maaari nilang tingnan ang patakaran ng share, ang pagiging miyembro ng account sa grupo at ang mga karapatan sa isang folder na iyon, at sabihin kung aling layer ang tumanggi sa iyo. Kung binanggit ng mensahe ang kapasidad, naka-lock na file o salungatan ng pangalan, ibang problema iyon at karapat-dapat sa sariling imbestigasyon.
I-verify ang pag-aayos, pagkatapos ay ilabas ayon sa pagkakasunod-sunod
Pagkatapos mong baguhin ng may-ari ang isang bagay, ulitin ang parehong maliit na pagsulat at kumpirmahin na nakikita ng server ang file at matatanggal pagkatapos. Ang kopyang nagsisimula at pagkatapos ay natigil ay tanong ng throughput, hindi ng permiso; ang pagtangging dumarating agad ay tanong ng permiso.
Bago bitawan ang VPN, i-unmount ang share at isara ang nakabukas na dokumento. Ang paglabas pagkatapos mawala ang tunnel ay nag-iiwan sa Finder at sa mga app mo na naghihintay sa patay na landas. Panatilihin ang SMB sa loob ng pribadong network, huwag patayin ang firewall para subukan ang teorya, at huwag buksan ang folder sa lahat bilang paraan ng pag-iwas. Para sa ticket, isama ang address, pangalan ng account, bigong operasyon, eksaktong teksto ng mensahe at oras, at iwanan sa labas ang mga password at file ng profile.
- Niresolba ang address sa pribadong address na dinadaanan ng tunnel.
- Sumasagot ang port 445 at
smbutil viewnaglilista ng nilalayong share para sa nilalayong account. - Ang pagsulat na kailangan mo ay pinatutunayan ng bagong file, hindi ng umiiral na dokumento.