ફોન VPN પર છે, ફાઇલ સર્વર ping નો જવાબ આપે છે, અને ફાઇલ એપ હજી કહે છે કે કનેક્ટ થઈ શકતું નથી; અથવા કનેક્ટ થાય છે અને ડિવાઇસનો કોઈ એડિટર તેની યાદીમાંનું ખોલતું નથી. આ બે અલગ નિષ્ફળતાઓ છે, અને એક પણ ટનલ તૂટી હોવાનો અર્થ નથી. VPN ફક્ત ખાનગી નેટવર્કમાં માર્ગ આપે છે; શેર બ્રાઉઝ કરવું, તેમાં પ્રમાણીકરણ કરવું અને દસ્તાવેજ બીજી એપને આપવો એ અલગ પગલાં છે, દરેકની અલગ નિષ્ફળતાની રીત છે. નીચે હું જે ક્રમમાં તપાસ કરું છું અને અનુમાન કરવાને બદલે જ્યાં થોભું છું તે છે.

ટનલને દોષ આપતા પહેલા સેવા તપાસો

ping નો જવાબ કે NAS નું વેબ પેજ ફક્ત રાઉટિંગ સાબિત કરે છે, બીજું કંઈ નહીં. તમને ખરેખર જે સેવા જોઈએ, 445 પર SMB, 22 પર SFTP કે 443 પર WebDAV, તે બંધ, ફાયરવોલથી અવરોધિત કે VPN સબનેટ ન પહોંચે એવા ઇન્ટરફેસ સાથે જોડાયેલી હોઈ શકે છે. ફોનથી તે ચોક્કસ પોર્ટ ખરી ભૂલ દેખાડતા ક્લાયન્ટથી ચકાસો. પોર્ટ ફિલ્ટર થયેલો હોય તો સેવા કે ફાયરવોલ નિયમ સુધારો, કારણ કે બંધ પોર્ટને કોઈ ફાઇલ એપ વટાવી શકતી નથી.

સર્વર કયું સ્રોત સરનામું જુએ છે તે પણ તપાસો. શેરનું સબનેટ બાકાત રાખતી સ્પ્લિટ ટનલ, કે ફાઇલ એપને VPN ની બહાર રાખતી પ્રતિ-એપ ટનલ, બરાબર જોડાયેલું પણ ન પહોંચી શકાય એવું લક્ષણ આપે છે.

એક ક્લાયન્ટ પ્રમાણીકરણ ન કરી શકે તેથી મહેમાન પ્રવેશ કે SMB1 ચાલુ કરવાનો ટૂંકો રસ્તો ન લો. એવા ફેરફારો નેટવર્કના દરેક ડિવાઇસ માટે સર્વર જે સ્વીકારે તે વિસ્તારે છે, અને મૂળ સમસ્યા રાઉટિંગ કે નામ-ઉકેલ હોય તો કંઈ સુધારતા નથી.

પ્રોટોકોલ જાતે બોલતી ફાઇલ એપ વાપરો

Android માં નેટવર્ક શેર માટે આંતરિક બ્રાઉઝર નથી, તેથી ક્લાયન્ટ એપ ખરેખર આધાર છે, વિગત નહીં. તમે ખરેખર ચલાવો છો તે પ્રોટોકોલ લાગુ કરતી અને હજી સંભાળાતી એક પસંદ કરો, કારણ કે તમે ન વાપરતા Android આવૃત્તિ માટે બનેલો ક્લાયન્ટ નેટવર્ક ખામી જેવો દેખાતો ભંગ પામે છે.

DNS ને રાઉટિંગથી અલગ કરવા એક વાર IP થી સર્વર અજમાવો. IP કામ કરે અને નામ ન કરે તો ફોન તમારો ખાનગી ઝોન ન જોતા DNS સર્વર દ્વારા ઉકેલે છે.

સ્વીકારતી એપને શું મળે છે: URI, માર્ગ નહીં

તમારી ફાઇલ એપ DocumentsProvider લાગુ કરે તો Android નું Storage Access Framework તેનો સમાવિષ્ટ સિસ્ટમ પસંદગીકારમાં દેખાડી શકે છે, અને તમે પસંદ કરેલી એપને content:// URI અને પરવાનગી મળે છે. એ પરવાનગી ફાઇલસિસ્ટમ માર્ગ નથી, તેથી કાચો માર્ગ માગતો એડિટર દસ્તાવેજ ખોલી શકતો નથી. Android દસ્તાવેજ પ્રવેશ માર્ગદર્શિકા આ નમૂનો સમજાવે છે.

વૈકલ્પિક રસ્તો જાણી જોઈને નકલ કરવાનો છે: ફાઇલ એડિટરની પોતાની સંગ્રહમાં ખેંચો, સંપાદિત કરો અને પાછી અપલોડ કરો. આ સારો કાર્યપ્રવાહ છે, પણ બીજી નકલ અને વિરોધનો પ્રશ્ન ઊભો કરે છે, તેથી ટ્રેનમાં સંપાદન શરૂ કરતા પહેલા કઈ બાજુ જીતશે તે નક્કી કરો.

પ્રતિ-એપ VPN નીતિ પણ જોવા જેવી છે. નેટવર્ક વાંચન કરતું પેકેજ ઘણી વાર પ્રદાતા એપ હોય છે, એડિટર નહીં, તેથી તમે દબાવેલા આઇકન પરથી આંકવાને બદલે યોગ્ય પેકેજ ટનલમાં સામેલ કરો.

વાંચન, લેખન અને પરવાનગીની ટકાવારી અલગ અલગ ચકાસો

ડિરેક્ટરી યાદી ફક્ત વાંચન માર્ગ સાબિત કરે છે. નિરુપદ્રવી ચકાસણી ફાઇલ લો અને આખો ક્રમ ચાલો: યાદી, ખોલો, સંપાદિત કરો, સંગ્રહો, પછી એ જ ફાઇલ ડેસ્કટોપ ક્લાયન્ટથી ફરી ખોલો.

પુનઃપ્રારંભ પછી પરવાનગી ટકે છે કે નહીં તે જુઓ. એપ કાયમી ન બનાવે તો સંગ્રહ પરવાનગી કામચલાઉ છે, કેટલાક એડિટર દર વખતે ફરી માગે છે જ્યારે બીજા શાંતિથી નિષ્ફળ થઈ જૂની નકલ દેખાડે છે. સંગ્રહ સફળ લાગે તો સર્વર પર સંશોધન સમય જોઈને ખાતરી કરો.

Android ની URI પરવાનગીને સર્વરની અધિકૃતિથી અલગ રાખો. દસ્તાવેજ ખોલવાની પરવાનગી તેની પાછળના SMB ખાતા વિશે કંઈ કહેતી નથી.

જેને જરૂર હોય તેવા કિસ્સાઓ માટે માઉન્ટ કરેલા શેર રાખો

મૂળ સ્તરના CIFS માઉન્ટ અને કર્નલ ફાઇલસિસ્ટમ મોડ્યુલ હજી છે, અને દરેક એપને સ્થાનિક ફોલ્ડરનો ભ્રમ આપે છે. પણ તેમને root જોઈએ, કર્નલ ફેરફારે તૂટે, અને નેટવર્ક ખામી ફાઇલસિસ્ટમ સ્તરમાં છુપાવે જ્યાં નિદાન કઠિન છે.

નેટવર્ક બદલાયા પછી માઉન્ટ ટકે છે કે નહીં તે તપાસો. ડેસ્ક પર લેપટોપથી માઉન્ટ કરેલું શેર Wi-Fi અને મોબાઇલ વચ્ચે ફરતા ફોન કરતાં અલગ વર્તે છે, અને જૂનું માઉન્ટ એપને લટકાવી શકે છે.

હજી અટકી રહ્યા હો તો યાદી ક્રમમાં કરો અને પ્રથમ નિષ્ફળ પગલે થોભો: પોર્ટ પહોંચે, પ્રોટોકોલ ક્લાયન્ટ સ્થાપિત, શેર પ્રમાણિત, પસંદગીકાર ફાઇલ દેખાડે, એડિટર URI સ્વીકારે, સંગ્રહ સર્વર પર પહોંચે. એ પગલું કયો ઘટક સુધારવો તે કહે છે, અને તે ભાગ્યે જ ટનલ હોય છે.

સંબંધિત લેખો