Las pruebas de origen separan claramente el permiso del servidor de la ruta del cliente Android. Al nuevo miembro se le concedió explícitamente acceso de lectura y escritura, y la misma carpeta compartida funcionó desde un ordenador. ZimaClient para Android siguió mostrando Permiso denegado en dos teléfonos incluso después de reinstalar la aplicación.
Eso no demuestra que exista un error específico de ZimaClient, porque ningún miembro del personal de IceWhale diagnosticó el hilo. Sí significa que «olvidaste conceder acceso al miembro» es una explicación incompleta. ZimaOS admite oficialmente permisos de carpetas por usuario, por lo que una reproducción actual debería comparar las mismas credenciales mediante ZimaClient y SMB directo antes de cambiar las ACL del servidor.
Primero, confirma la ACL del recurso compartido en el servidor
La guía actual de IceWhale para Samba multiusuario indica que el administrador debe asignar un miembro a la carpeta compartida y elegir Lectura o Lectura y escritura.
Usa el flujo actual de ZimaOS para compartir con miembros.
La prueba en el ordenador demuestra que las credenciales del miembro pueden funcionar
El autor original indicó que se podía acceder a la carpeta compartida desde un ordenador. Esta es la prueba de aislamiento más útil del hilo, porque demuestra que el usuario, la cuenta y el recurso compartido pueden funcionar al menos mediante una ruta de cliente.
Que fallen dos teléfonos Android reduce la probabilidad de que una sola instalación de la aplicación esté dañada
El usuario intentó reinstalar ZimaClient y también probó con otro teléfono. Ambos siguieron mostrando Permiso denegado. Esto hace menos probable que se trate de una única caché dañada del teléfono, aunque no identifica el fallo real de autenticación móvil.
Prueba SMB directo desde Android
Una respuesta de la comunidad sugirió probar el mismo nombre de usuario y contraseña con un cliente SMB normal para Android. Si SMB directo funciona mientras ZimaClient falla, las pruebas apuntan aún más claramente a la capa de ZimaClient o de la sesión, y no a las ACL de Samba.
Si ambos fallan, revisa las credenciales SMB exactas, el formato del nombre de usuario, los caracteres especiales y el estado de la cuenta en el servidor.
Termina por completo la sesión existente de ZimaClient
Es posible que cambiar los permisos del miembro no actualice inmediatamente una sesión de cliente ya autenticada. Cierra sesión, elimina el dispositivo o la sesión guardada si el cliente actual lo requiere, vuelve a conectarte y prueba de nuevo el mismo recurso compartido.
Vuelve a probar con ZimaOS y ZimaClient actuales
La fuente usaba ZimaOS 1.6.1. Las versiones actuales de ZimaOS y de los clientes móviles han cambiado. La documentación actual de ZimaOS confirma que los permisos están vinculados a las cuentas de ZimaOS y que ZimaClient proporciona acceso local y remoto.
Las desconexiones móviles posteriores fueron un síntoma distinto
Más tarde, el autor original indicó que la copia de seguridad del teléfono funcionaba, pero que la conexión móvil se interrumpía con frecuencia. El hilo no estableció si se trataba del mismo problema de permisos, de un problema de red o P2P, o de otra regresión del cliente.
Mantén «Permiso denegado» y «conexión perdida» como casos de prueba independientes, a menos que los registros indiquen una causa común.
Preguntas frecuentes sobre el acceso de miembros desde Android
¿Los permisos del miembro estaban configurados visiblemente en la fuente?
Sí. Las capturas mostraban al miembro y la carpeta con acceso de lectura y escritura.
¿La carpeta funcionaba desde un ordenador?
Sí, por eso las pruebas de origen apuntan a que no se trata de un error básico de la ACL del recurso compartido.
¿El hilo confirmó una solución de IceWhale?
No. Terminó con el problema de Android aún sin resolver.
