"Los permisos de Android son una bestia".
En desktop-Linux si tienes permisos de Root te estropeas para poder hacer de todo (bueno o malo). Descubrí, que en Android aunque ejecutes algo con permisos Root, todavía no puedes hacer todo lo que quieres en el momento. Sigues necesitando algunos ajustes. Tal vez sea mejor así ...
A continuación explicaré cómo monté con éxito mi sftp-share en un punto de montaje usando Termux, y lo hice accesible a todos los usuarios/apps/exploradores de archivos. Créditos a MountainX. En su post ¿Cómo automatizar rclone-mount sin Termux o Magisk? él preparó el camino para romper la jungla de permisos para el montaje de clones sin Magisk/Termux. Sin embargo, creo que uno puede hacerlo dentro de Termux/Magisk también. La ventaja obvia es la posibilidad de hacer scripts, cronjobs para comprobar/restaurar regularmente las conexiones, etc.
Pasos:
- He instalado openssh en Termux, y he ejecutado el
sshd demonio. Todos los pasos siguientes se realizaron a través de una conexión ssh desde el emulador de terminal de un ordenador de sobremesa. Ventaja principal: uno puede tener múltiples conexiones ssh, por ejemplo una como Root-CLI, una segunda como normal-user-CLI, una tercera con 'midnight-commander' para comprobar los resultados del montaje.
- En Magisk-Manager-Settings del dispositivo Android encuentra la opción "Namespace" y elige "Global namespace" o "Inherited namespace" (de momento funciona con ambos, si encuentro algún problema en el futuro editaré la respuesta).
- Los ejecutables rclone y montaje de fusibles Debe estar en /sistema/bin Y tener la propiedad sistema:shell . NO root:root . Al parecer, cuando se lanzan de esa manera se abren paso a través de la jungla de permisos. Otras combinaciones no funcionan (por ejemplo, los propietarios cambiados pero lanzados desde otro directorio). Pero no es sencillo cómo copiarlos en /sistema/bin porque generalmente se monta de sólo lectura. Suponiendo que ambos archivos ya están instalados en /data/data/com.termux/files/usr/bin debemos (a) hacer /sistema/bin escribibles, (b) copiarlos (c) cambiar la propiedad y el mod, (d) restaurar /sistema/bin como de sólo lectura.
En Termux:
$ su
# mount -o rw,remount /system
# cp /data/data/com.termux/files/usr/bin/rclone /system/bin/
# cp /data/data/com.termux/files/usr/bin/fusermount /system/bin/
# chown system:shell /system/bin/rclone
# chmod 775 /system/bin/rclone
# chown system:shell /system/bin/fusermount
# chmod 775 /system/bin/fusermount
# mount -o ro,remount /system
# exit
$
- Ahora podemos lanzar rclone/fusermount a través de su -c "XXXX" de nuevo, pero esta vez a través de su /sistema/bin/ copias. Por cierto, ya no es necesario pasar la variable $PATH. En mi búsqueda descubrí la opción su --mount-master también.
su --mount-master -c "HOME=$HOME rclone -vvv mount sshfs-srv-rasp1: /storage/emulated/legacy/srv-rasp1 --allow-other"
Mientras el comando anterior esté en funcionamiento, el punto de montaje /almacenamiento/emulado/legado/srv-rasp1 está vinculado con éxito al sftp-share. La opción "--allow-other" permite que otros usuarios que no sean Root tengan acceso. Pude confirmar el acceso a través de una conexión ssh separada con 'midnight-commander'. Pero en el momento en que el comando es matado con Ctrl-c, la conexión se cierra.
- Puedes añadir la opción "--daemon" para que se ejecute en segundo plano. Puedes comprobar en cualquier momento que rclone sigue vivo con
pgrep rclone
- Para matar la conexión con elegancia:
su -c "fusermount -u -z /storage/emulated/legacy/srv-rasp1" . Tenga en cuenta la opción -z ("lazy"): fuerza el desmontaje incluso cuando alguien está usando el recurso compartido. Este comando mata a rclone en segundo plano (compruébelo con pgrep).
- En caso de que te preguntes por qué uso /almacenamiento/emulado/ legado /XXXX como path-to-mount-point, descubrí, que termux y su -c "XXXX" ven cosas diferentes bajo /storage/emulated.
Compruébalo:
$ ls /storage/emulated
0 legacy
$ su -c "ls /storage/emulated"
legacy
- Curiosamente, ambos /almacenamiento/emulado/ 0 y /almacenamiento/emulado/ legado se refieren a la misma tarjeta SD interna. Como el comando rclone se ejecuta a través de su -c "XXXX", decidí utilizar el denominador común "legacy". Tienes que comprobar en tu dispositivo la ruta exacta a través de la cual su -c "XXXX" ve la tarjeta SD interna.
Hasta ahora, nuestro sftp-share es accesible sólo dentro de termux. Otras aplicaciones (por ejemplo, File-Explorer) no tienen acceso. Esto tiene que ver con la propiedad/permiso otorgado al punto de montaje por rclone.
Comprueba mientras rclone se está ejecutando:
ls -l /storage/emulated/legacy/
drwxrwx--- 2 root sdcard_r 4096 Jan 1 2014 Alarms
drwxrwx--x 5 root sdcard_r 4096 Sep 22 17:47 Android
drwxrwx--- 2 root sdcard_r 4096 Jan 1 2014 DCIM
drwxrwx--- 3 root sdcard_r 4096 Oct 6 18:14 Documents
drwxrwx--- 3 root sdcard_r 4096 Oct 8 17:28 Download
...
drwxr-xr-x 1 root root 0 Oct 9 14:38 srv-rasp1
La propiedad del punto de montaje srv-rasp1 es Root:Root. Cambiar la propiedad fuera de la conexión no tiene efecto: rclone concede de nuevo Root:Root. Incluso mi ES-Explorer rooteado no pudo ver el contenido de srv-rasp1. La solución es ajustar las propiedades en rclone: --gid 9997 --dir-perms 0771 --file-perms 0660 --umask=0
El mando hasta ahora:
su --mount-master -c "HOME=$HOME rclone -vvv mount sshfs-srv-rasp1: /storage/emulated/legacy/srv-rasp1 --gid 9997 --dir-perms 0771 --file-perms 0660 --umask=0 --allow-other --daemon"
Vuelve a comprobar las titularidades/permisos:
$ ls -l /storage/emulated/legacy
drwxrwx--- 2 root sdcard_r 4096 Jan 1 2014 Alarms
drwxrwx--x 5 root sdcard_r 4096 Sep 22 17:47 Android
drwxrwx--- 2 root sdcard_r 4096 Jan 1 2014 DCIM
drwxrwx--- 3 root sdcard_r 4096 Oct 6 18:14 Documents
drwxrwx--- 3 root sdcard_r 4096 Oct 8 17:28 Download
...
drwxrwx--x 1 root everybody 0 Oct 9 14:46 srv-rasp1
Voilà. Al punto de montaje srv-rasp1 se le dio la propiedad de grupo "todos". ES-Explorer y todas las demás aplicaciones pueden ahora acceder a ver el contenido del montaje srv-rasp1.
Algunos comentarios, ligeramente ajenos a la pregunta, pero igualmente interesantes:
- rclone monta como directorio "Root" por defecto no el Root real ("/") sino el directorio HOME ("/home/XXXX/") del usuario que se registra en el servidor ssh/sftp. Para anular esto, encontré una respuesta no muy clara aquí: https://github.com/rclone/rclone/issues/4307 . Experimentando, descubrí que rclone acepta la sintaxis general del comando sshfs de Linux: servidor:/ruta/al/montaje/ con la observación de que en lugar de "servidor" damos el nombre de la configuración. Así, si quiero montar srv-rasp1/mnt/ Simplemente tengo que escribir:
... rclone mount sshfs-srv-rasp1:/mnt /storage/emulated/legacy/srv-rasp1 ... . El punto de montaje mostrará ahora el contenido de srv-rasp1/mnt/
- En su post MountainX añade algunas opciones de rclone con respecto a vfs y cosas de caché. Esto va más allá de mis conocimientos pero parece que consigue una interacción sin fisuras entre dispositivo <-> servidor, escritura/lectura simultánea, etc. Simplemente las he añadido a la línea de comandos.
Debajo de mi comando final:
su --mount-master -c "HOME=$HOME rclone -vvv mount sshfs-srv-rasp1:/mnt /storage/emulated/legacy/srv-rasp1 --gid 9997 --dir-perms 0771 --file-perms 0660 --umask=0 --cache-dir /storage/emulated/legacy/.cache --vfs-cache-mode full --vfs-cache-max-age 2h0m0s --vfs-cache-poll-interval 5m0s --allow-other --daemon"
En mi entorno, no necesitaba:
- para retocar cualquier cosa relacionada con SELinux (ver también el comentario de MountainX en el enlace mencionado).
- para pasar cualquier variable ambiental de Termux relativa a las bibliotecas (por ejemplo, LD_LIBRARY_PATH=$LD_LIBRARY_PATH). Los ejecutables rclone y fusermount son independientes, no necesitan ninguna biblioteca externa.
- para modificar cualquier cosa relacionada con los espacios de nombres (por ejemplo readlink o nsenter como sugirió Irfan Latif (véase ¿Cómo montar rclone en Android? )
Sin embargo, no puedo excluir que los ajustes mencionados puedan ser necesarios en otros escenarios. Por esta razón los menciono.
0 votos
Lo más probable es que esté relacionado con el espacio de nombres de montaje o SELinux. Ya comunicado por otros . En lugar de utilizar
sudoosu -cotsu -cmejor abrir un shell Root y ejecutar comandos desde allí. También puede utilizarstracepara obtener el error con mayor precisión. Y espero que hayas pasado por esta respuesta mía.