Skip to content

Conversation

@Genaker
Copy link

@Genaker Genaker commented Dec 11, 2025

Added ACL support check and fallback to traditional permissions. Improved error handling for permission setting.

On Warden docker environment command "composer install" error : > Oro\Bundle\InstallerBundle\Composer\ScriptHandler::setPermissions Script Oro\Bundle\InstallerBundle\Composer\ScriptHandler::setPermissions handling the set-permissions event terminated with an exception The following exception is caused by a process timeout Check https://getcomposer.org/doc/06-config.md#process-timeout for details

In Process.php line 1205:

The process "setfacl -Rm "u:whoami:rwX,d:u:whoami:rwX,g:whoami:rw,d:g:whoami:rw" var/cache" exceeded the timeout of 60 seconds.

image

full log:

composer install
Gathering patches from patch file.
No patches supplied.
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. It is recommended that you run `composer update` or `composer update <package name>`.
Nothing to install, update or remove
Package behat/transliterator is abandoned, you should avoid using it. No replacement was suggested.
Package box/spout is abandoned, you should avoid using it. No replacement was suggested.
Package doctrine/annotations is abandoned, you should avoid using it. No replacement was suggested.
Package doctrine/cache is abandoned, you should avoid using it. No replacement was suggested.
Package laminas/laminas-loader is abandoned, you should avoid using it. No replacement was suggested.
Package sensio/framework-extra-bundle is abandoned, you should avoid using it. Use Symfony instead.
Generating autoload files
167 packages you are using are looking for funding.
Use the `composer fund` command to find out more!

> Oro\Bundle\InstallerBundle\Composer\ScriptHandler::setPermissions
Script Oro\Bundle\InstallerBundle\Composer\ScriptHandler::setPermissions handling the set-permissions event terminated with an exception
The following exception is caused by a process timeout
Check https://getcomposer.org/doc/06-config.md#process-timeout for details

In Process.php line 1205:
                                                                                                                                           
  The process "setfacl -Rm "u:`whoami`:rwX,d:u:`whoami`:rwX,g:`whoami`:rw,d:g:`whoami`:rw" var/cache" exceeded the timeout of 60 seconds.  

Added ACL support check and fallback to traditional permissions. Improved error handling for permission setting.

On Warden docker error : > Oro\Bundle\InstallerBundle\Composer\ScriptHandler::setPermissions
Script Oro\Bundle\InstallerBundle\Composer\ScriptHandler::setPermissions handling the set-permissions event terminated with an exception
The following exception is caused by a process timeout
Check https://getcomposer.org/doc/06-config.md#process-timeout for details

In Process.php line 1205:
                                                                                                                                           
  The process "setfacl -Rm "u:`whoami`:rwX,d:u:`whoami`:rwX,g:`whoami`:rw,d:g:`whoami`:rw" var/cache" exceeded the timeout of 60 seconds.
@mbessolov
Copy link
Member

@Genaker Can you clarify what you mean by "Warden docker"?

AFAIK, Warden does not yet support a compatible environment – https://docs.warden.dev/environments/types.html

setfacl is available on essentially all general-purpose Linux distributions, including Ubuntu, Debian, Fedora, RHEL, CentOS, Oracle Linux, SUSE/openSUSE, Arch Linux, Manjaro, Amazon Linux, etc.

RPM-based distributions such as RHEL, Oracle Linux, CentOS, and Fedora would align most closely with the production-proven environments used in OroCloud. Ubuntu, Debian, and Arch are also widely used by OroCommerce developers and fully support setfacl.

It may not be available on Alpine by default, and past experience shows that Alpine can introduce additional issues when running OroCommerce, so we cannot recommend it anyway.

@Genaker
Copy link
Author

Genaker commented Dec 12, 2025

It is on Centos 9 Docker when /var/www/html attached to the Windows host machine

@mbessolov
Copy link
Member

mbessolov commented Dec 12, 2025

@Genaker Please run the following command from inside the container and share the output:

stat -f -c '%T' /var/www/html

My guess is that your docker-compose.yml currently mounts the project from Windows similar to this:

volumes:
  - "C:/Users/someuser/orocommerce:/var/www/html"

In this setup, the source path is on NTFS and is exposed into the Linux container via Docker Desktop's file-sharing layer (9p / drvfs / virtiofs, depending on the configuration). In this case, POSIX ACLs are not available, so setfacl fails even though CentOS itself fully supports it.

I am still not sure we should allow running the installation without setfacl support though, as a Windows-backed bind mount like that introduces additional Linux filesystem gaps that can lead to other issues:

  • Case sensitivity is typically not enforced, which can hide non-obvious filename typos and only surface later when deploying to a real Linux production environment.
  • Inode support may also be missing or unstable, which can affect Symfony's change detection and lead to unexpectedly slow dev-mode behavior and continuous unnecessary cache rebuilds on each request.
  • Long file paths may also become an issue. With Windows-backed bind mounts, Windows path-length limits can surface as "File name too long" errors in Composer or as cache generation failures in Symfony - we've seen that before, reported by developers using Windows setups.

These problems can be avoided by keeping the project on a Linux filesystem and mounting it from there:

  • Store the project inside WSL (e.g., /home/<user>/orocommerce, accessible from Windows as \\wsl$\<distro>\home\<user>\orocommerce).
  • Run docker compose from within WSL. With Docker Desktop WSL integration enabled - containers are managed by Docker Desktop and remain fully visible and controllable in the Docker Desktop UI.

Projects stored inside WSL remain fully accessible from the Windows host even when containers are not running - Windows will automatically start WSL on access. The main thing to avoid though is unregistering the WSL distribution (for example via wsl --unregister), as that would remove the filesystem and its contents.

@mbessolov
Copy link
Member

Just a note for myself:

  • PowerShell: wsl --list --verbose
  • PowerShell: wsl --set-version CentOS-Stream-9 2
  • Docker Desktop > Settings > General: enable Use the WSL 2 based engine
  • Docker Desktop > Settings > Resources > WSL Integration: enable for CentOS
  • WSL shell: docker info
  • WSL shell: docker context ls

@Genaker
Copy link
Author

Genaker commented Dec 12, 2025 via email

@Genaker
Copy link
Author

Genaker commented Dec 12, 2025 via email

@mbessolov
Copy link
Member

It is not Centos 9 issue. But Mount issue to Windows host system:
microsoft/WSL#2750

I think that applies to NTFS filesystem exposed to WSL:

volumes:
  - "C:/Users/someuser/orocommerce:/var/www/html"

It will be avoided when:

Store the project inside WSL (e.g., /home//orocommerce, accessible from Windows as \wsl$<distro>\home<user>\orocommerce).

volumes:
  - /home/<user>/orocommerce:/var/www/html

The Windows will create a VHDX virtual disk, formatted as ext4 inside that VHDX, and made it available to the WSL Linux distro. That will be a true fully initialized Linux filesystem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants