Dowody ze źródła wyraźnie rozdzielają uprawnienia serwera od ścieżki klienta Android. Nowemu członkowi jawnie przyznano dostęp Read & Write, a ten sam folder współdzielony działał z komputera. ZimaClient na Androidzie nadal zwracał komunikat Permission Denied na dwóch telefonach, nawet po ponownej instalacji aplikacji.
Nie dowodzi to konkretnego błędu ZimaClient, ponieważ żaden pracownik IceWhale nie zdiagnozował tego wątku. Oznacza jednak, że wyjaśnienie „zapomniano przyznać członkowi dostęp” jest niepełne. Obecny ZimaOS oficjalnie obsługuje uprawnienia folderów dla poszczególnych użytkowników, dlatego przy aktualnej próbie odtworzenia problemu należy porównać te same dane logowania w ZimaClient i bezpośrednio przez SMB przed zmianą list kontroli dostępu serwera.
Najpierw potwierdź listę kontroli dostępu udziału po stronie serwera
Aktualne wytyczne IceWhale dotyczące wieloużytkownikowej Samby zakładają, że administrator przypisuje członka do folderu współdzielonego i wybiera uprawnienie Read albo Read & Write.
Skorzystaj z aktualnej procedury konfiguracji udziałów członków w ZimaOS.
Test na komputerze pokazuje, że dane logowania członka mogą działać
Autor pierwotnego wpisu powiedział, że folder współdzielony był dostępny z komputera. To najbardziej przydatny test izolacyjny w tym wątku, ponieważ pokazuje, że użytkownik, konto i udział mogą działać przynajmniej za pośrednictwem jednej ścieżki klienta.
Problemy na dwóch telefonach z Androidem zmniejszają prawdopodobieństwo uszkodzenia jednej instalacji aplikacji
Użytkownik ponownie zainstalował ZimaClient i przetestował także inny telefon. W obu przypadkach nadal pojawiał się komunikat Permission Denied. Zmniejsza to prawdopodobieństwo uszkodzenia pamięci podręcznej jednego telefonu, choć nie wskazuje rzeczywistej przyczyny błędu uwierzytelniania na urządzeniu mobilnym.
Przetestuj bezpośrednie połączenie SMB z Androida
W odpowiedzi społeczności zasugerowano użycie tych samych nazw użytkownika i haseł w zwykłym kliencie SMB na Androida. Jeśli bezpośrednie SMB zadziała, a ZimaClient nie, dowody będą jeszcze wyraźniej wskazywać na warstwę sesji ZimaClient, a nie na listy kontroli dostępu Samby.
Jeśli oba sposoby zawiodą, sprawdź dokładne dane logowania SMB, format nazwy użytkownika, znaki specjalne oraz stan konta po stronie serwera.
Całkowicie zakończ istniejącą sesję ZimaClient
Zmiana uprawnień członka może nie zaktualizować natychmiast uwierzytelnionej sesji klienta. Wyloguj się, w razie potrzeby usuń zapisane urządzenie lub sesję zgodnie z wymaganiami bieżącego klienta, połącz się ponownie i ponownie przetestuj ten sam udział.
Ponownie przetestuj problem na aktualnych wersjach ZimaOS i ZimaClient
Źródło dotyczyło ZimaOS 1.6.1. Obecne wersje ZimaOS i klientów mobilnych uległy zmianom. Aktualna dokumentacja ZimaOS potwierdza, że uprawnienia są powiązane z kontami ZimaOS, a ZimaClient zapewnia dostęp lokalny i zdalny.
Późniejsze rozłączanie połączenia mobilnego było osobnym objawem
Autor wpisu napisał później, że kopia zapasowa telefonu działała, ale połączenie mobilne często się rozłączało. Wątek nie ustalił, czy był to ten sam problem z uprawnieniami, problem z siecią lub P2P, czy też inna regresja klienta.
Traktuj „Permission Denied” i „connection lost” jako osobne przypadki testowe, chyba że dzienniki wskażą wspólną przyczynę.
Najczęstsze pytania dotyczące dostępu członka z Androida
Czy uprawnienia członka były widocznie skonfigurowane w źródle?
Tak. Zrzuty ekranu pokazywały członka i folder z dostępem Read & Write.
Czy folder działał z komputera?
Tak, dlatego dowody ze źródła wskazują raczej na coś innego niż podstawowy błąd listy kontroli dostępu udziału.
Czy wątek potwierdził poprawkę IceWhale?
Nie. Zakończył się, gdy problem z Androidem nadal pozostawał nierozwiązany.
