Composer could not find a composer.json file in /var/www/html
Stefan Bogdanescu
Founder & Senior Architect · 2026-06-29
# Solving the Composer Permission Nightmare: Why `laravel new project` Fails
As senior developers, we often deal with environments where setup scripts and permissions clash. Setting up build tools like Composer, especially in Virtual Machines or shared hosting environments, frequently runs into frustrating permission errors. The scenario you described—successfully installing Composer globally but failing when trying to initialize a Laravel project—is a classic example of this conflict.
This post will dissect why you encountered the "Permission denied" errors and how to correctly structure your environment to ensure smooth project initialization, aligning with best practices for modern PHP development, particularly within the Laravel ecosystem.
## Deconstructing the Error: Permissions vs. Execution
You followed the standard steps for installing Composer globally and setting up the PATH. However, the subsequent failure points directly to file system permissions, not necessarily a flaw in the Composer installation itself.
The critical error messages were:
```
PHP Warning: file_put_contents(/var/www/html/laravel_62a1f2f16d54929f3367e5f18f937a47.zip): failed to open stream: Permission denied
PHP Warning: ZipArchive::extractTo(): Permission denied
```
These warnings indicate that the user account executing the `laravel installer` process did not have the necessary write permissions for the `/var/www/html` directory where it attempted to create or extract project files. Even though you used `sudo` for installing Composer, the subsequent execution of the Laravel installer likely ran under a different context, leading to this permission denial when writing new project structures.
## The Root Cause: Execution Context and Ownership
The core issue lies in *where* the operation is being attempted. When working on a Virtual Machine or web server environment (like Ubuntu), directories like `/var/www/html` are typically owned by the `root` user, which standard non-root users do not have permission to write into without explicit privileges.
Attempting to run commands that modify system-level directories from a non-privileged shell context often results in "Permission denied."
## The Solution: Best Practices for Project Setup
Instead of forcing project creation into a root-owned directory, the solution is to ensure you are operating within a user-owned space where file operations are permitted.
### 1. Change Your Working Directory
Never attempt to create application code directly in sensitive system directories like `/var/www/html` unless you explicitly intend for that web server process to own the files. For development purposes, stick to your home directory or dedicated project folders.
**Correct Approach:** Navigate to a personal space before running framework commands:
```bash
# Create a dedicated development space in your home directory
mkdir ~/projects
cd ~/projects
# Now run the Laravel installer
composer global require "laravel/installer"
laravel new my-new-project
```
By executing these steps from `~/projects`, you ensure that Composer and the Laravel installer have full read/write permissions for the files being created, completely bypassing the previous permission denial errors.
### 2. Reevaluating Global Installation (Advanced Tip)
While modifying your `.profile` file to set the PATH is a valid method for making commands globally accessible, for many complex environments, managing dependencies via local project directories or dedicated development accounts is safer. If you are setting up a persistent environment, consider using tools like Docker, which encapsulates the entire operating system context and eliminates these kinds of host permission conflicts entirely.
## Conclusion
Troubleshooting setup issues often involves looking beyond the immediate command failure to understand the underlying file system context. In this case, the error was not about Composer's ability to find files, but its inability to write them due to strict Linux permissions. By shifting your development workflow to user-owned directories and adhering to secure execution contexts, you ensure that your tools—whether Composer or the Laravel installer—can perform their tasks without interference. For robust application development, always prioritize file permissions alongside command syntax, as demonstrated by the principles behind managing dependencies on platforms like [laravelcompany.com](https://laravelcompany.com).