Tengo una aplicación Laravel implementada en Azure Kubernetes con docker. Mi aplicación tiene problemas para cargar archivos cada vez que intento cargar un archivo. Aparece este error de Laravel (que muestra solo una parte del seguimiento de la pila):
chmod(): Operación no permitida {"userId":1,"exception":"[object] (ErrorException(code: 0): chmod(): Operación no permitida en /var/www/my-app/vendor/league /flysystem/src/Adapter/Local.php:367) [traza de pila]
#0 [función interna]: Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(2, 'chmod(): Operat...', '/var/www/my-app...', 367, Array)
#1 /var/www/my-app/vendor/league/flysystem/src/Adapter/Local.php(367): chmod('/var/www/my-app...', 420)
Sin embargo, en mi Dockerfile he "choqueado" la carpeta de almacenamiento:
RUN chown -R www-data:www-data \ /var/www/my-app/storage \ /var/www/my-app/bootstrap/cache Debo mencionar que el archivo se carga pero no continúa con el resto del código debido a la excepción chmod .
En un intento de depurar el problema, ejecuté kubectl exec para obtener un shell en el pod, por defecto inicia sesión como raíz. Hago un cd a los archivos cargados e intento cambiar los permisos como root ejecutando chmod 420 nameOfFile.ext y funciona, así que lo cambio de nuevo a los permisos 777. Sin embargo, dado que Laravel está usando el usuario de apache "www-data", ejecuto su www-data -s /bin/bash luego intente cambiar el permiso del mismo archivo ejecutando chmod 420 nameOfFile.ext y obtengo este error:
chmod: cambio de permisos de "nameOfFile.ext" Operación no permitida
Eso me dejó preguntándome si la '-R' en chown solo funcionaba en archivos y carpetas que eran directamente un subarchivo o carpeta. Así que cambié de nuevo al usuario raíz 'chown' la carpeta donde estaban los archivos directamente, luego cambié de nuevo al usuario www-data e intenté ejecutar chmod en el archivo pero aún recibí el mismo error.
[EDITAR] También debo mencionar que la aplicación usa el servicio de archivos de Azure como volumen persistente. ¿Ayudaría cambiarlo a un servicio de blob?
[EDITAR] Así es como se ve mi Dockerfile completo: https://pastebin.com/zLSyfqK8
He estado en este tema por un tiempo, cualquier ayuda es apreciada. Avíseme si necesita cualquier otra información necesaria.
También debo mencionar que la aplicación usa el servicio de archivos de Azure como volumen persistente.
Ese es el problema. Azure Files proporciona un recurso compartido CIFS, que se monta en Linux como un montaje cifs . Los recursos compartidos de CIFS no proporcionan permisos de archivos de tipo UNIX ni almacenamiento uid/gid de tipo UNIX.
Al montar el recurso compartido CIFS, la máquina Linux usa un nombre de usuario/contraseña para autenticarse en el servidor CIFS. Cada acceso a través de este montaje utilizará este nombre de usuario en el servidor CIFS, independientemente de qué usuario de UNIX esté iniciando las operaciones del sistema de archivos. Según este problema de GitHub , Azure Files no admite extensiones de UNIX, lo que significa que el cliente de Linux tendría que emular UNIX uid/gid y permisos. El servidor no almacena ni proporciona estos parámetros. Entonces, en el momento del montaje, debe agregar los parámetros uid , gid , file_mode y dir_mode para configurar estos datos.
Si está utilizando montajes CIFS a nivel de sistema operativo (a través de /etc/fstab ), o comandos de montaje CLI manuales, debe agregar estas opciones al comando de montaje (consulte man mount.cifs ).
Por ejemplo: mount -t cifs -o file_mode=0644,dir_mode=0755,uid=80,gid=80 ...
Si usa volúmenes de Kubernetes, debe agregar estas opciones a los parámetros del volumen (consulte Compartir Azure Files en Kubernetes ).
P.ej:
apiVersion: v1 kind: PersistentVolume metadata: name: azurefile spec: capacity: storage: 5Gi accessModes: - ReadWriteMany storageClassName: azurefile azureFile: secretName: azure-secret shareName: aksshare readOnly: false mountOptions: - dir_mode=0755 - file_mode=0644 - uid=80 - gid=80 - mfsymlinks