Improve sugar_mkdir error handling

rsp · 30 June 2026 21:05

Thank you for creating this PR

github.com/SuiteCRM/SuiteCRM

Improve sugar_mkdir error handling

hotfix ← pgorod:patch-16

opened 11:06AM - 29 Jun 26 UTC

pgorod

+21 -3

## Enhanced error handling for directory creation **TLDR; sugar_mkdir failure…s should be considered critical, and a proper message should _always_ be logged. Failures should be circumvented when possible.** A good number of people showing up in the forums with broken initial installations is stumbling with the typical ownership-permissions errors. Although this problem is "classical", there are some new factors at play due to the change to Suite8 and to the modernization of PHP. - Added fallback for permission errors which are appearing in modern Ubuntu's etc due to PHP-FPM hardening - Improved logging in some early moments of installation when the normal log is not available yet or the log level is not sufficient. This really helps to prevent critical, yet silent failures that leave people clueless - this new code is much better at showing permissions errors for what they are, instead of letting them creep up later as - missing CSS - missing screen elements - during initial login as "Login credentials incorrect" ## Motivation and Context I spent two days installing SuiteCRM on Ubuntu 26. I am a pro at installing SuiteCRM. If it takes me 2 days, most other people will likely just give up. Granted, it took me 2 days because I wasn't just trying to get it to work, I was stubbornly trying to understand _why_ it wasn't working, connecting a debugger, making sure each problem I discovered was getting properly logged etc. ## How To Test This This helper sugar_mkdir function is used all over the place, so it affects basically everything. But the two main test cases I would recommend looking at: 1. initial installation, in Ubuntu 26, with PHP-FPM, using a permissions scheme which includes a SetGID bit: `2775` or similar. 2. in normal usage after already installed, delete the entire cache dir and see if recovers well: `sudo rm -rf /var/www/suitecrm/public/legacy/cache/` You can also redo those two test cases but with broken permissions. 1. try an initial install with broken ownerships or permissions, check that you can see a relevant log message indicating this (might show up in `php_errors.log` or in `suitecrm.log` (v7) or in `logs/prod/prod.log` (v8) 2. in normal usage after already installed, delete the entire cache dir and recreate it manually with some incorrect ownerships, for example, so that it is not writable. Check that you can see a relevant log message indicating this. ## Types of changes - [X] Bug fix (non-breaking change which fixes an issue) - [X] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) ### Final checklist - [X] My code follows the code style of this project found [here](https://docs.suitecrm.com/community/contributing-code/coding-standards/). - [ ] My change requires a change to the documentation. - [X] I have read the [**How to Contribute**](https://docs.suitecrm.com/community/contributing-code/) guidelines.