The "PHP file_put_contents: Failed to open stream: Permission denied" error occurs when the PHP process, running under the Apache user (typically www-data), lacks write access to the target directory or file. Resolving this requires correcting ownership and permissions on the affected paths so that the web server can modify files without compromising system security.
Understanding the Root Cause
In Ubuntu systems running the LAMP stack, PHP scripts executed via the Apache HTTP Server do not run as your personal user account. Instead, they operate under thewww-data user and group. When you attempt to use file_put_contents() to write a file, the operating system checks if the www-data user has the necessary write privileges for that specific location. If the file or its parent directory is owned by your regular Linux user (e.g., your_username) and does not grant group or other write permissions, the operation fails immediately with a permission denied error. This is a deliberate security feature preventing web applications from arbitrarily modifying system files or other users' data.
Identifying the Current Permissions
Before making changes, verify the current state of the directory causing the issue. Open your terminal and navigate to the document root, typically/var/www/html or a custom subdirectory. Use the ls -l command to inspect the ownership and permission bits. You will likely see an output where the owner is listed as your username rather than www-data. For example:
drwxr-xr-x 2 your_username your_username 4096 Oct 10 10:00 uploads/
r-x permissions for the group and others mean they can read and execute but cannot write. Since Apache runs as www-data, it falls into the "others" category if it is not in the group, or the "group" category if it matches, but neither has write access. Understanding this distinction is crucial before applying fixes.
Solution 1: Changing Ownership to www-data
The most robust solution for development environments or dedicated web servers is to transfer ownership of the web-accessible directories to thewww-data user. This ensures that both PHP and manual file management via SSH are handled consistently. You can change the owner and group recursively using the chown command.
Run the following command in your terminal, replacing /var/www/html with your actual project path:
sudo chown -R www-data:www-data /var/www/html
ls -l. The owner should now be www-data. While this solves the immediate permission error, be cautious if multiple developers need to edit files directly via FTP or SFTP, as their user accounts may lose write access to these files. For teams requiring collaborative editing, consider using groups instead, as discussed in related troubleshooting guides such as Ubuntu 20.04: Permission Error when Writing to /var/www/html.
Solution 2: Adjusting Directory Permissions
If changing ownership is not feasible due to multi-user constraints, you must adjust the permission bits to allow writing. Directories require the execute bit (x) to be traversable, and the write bit (w) to allow creating new files. Files generally only need the write bit.
To grant write access to the group, add the group to the www-data group and set appropriate permissions. First, add your user to the www-data group:
sudo usermod -aG www-data $USER
775 (read, write, execute for owner and group; read, execute for others) and file permissions to 664:
find /var/www/html -type d -exec chmod 775 {} \;
find /var/www/html -type f -exec chmod 664 {} \;
www-data user (via group membership) to write files while keeping them readable by others. It is a balanced approach for shared hosting environments. However, ensure that sensitive configuration files are not exposed with overly permissive settings.
Handling Specific File Locks
Sometimes, even with correct permissions, you might encounter errors if a file is locked by another process. Ensure no other service is holding a lock on the target file. You can check for locks usingfuser or by reviewing active processes. Additionally, if you are writing to a cache directory, clear any stale files that might have incorrect attributes from previous failed attempts.
Solution 3: Using ACLs for Granular Control
For advanced scenarios where you need fine-grained control over who can read or write specific files, Access Control Lists (ACLs) provide a more flexible alternative to standard Unix permissions. Install the ACL package if it is not already present:sudo apt install acl
www-data user on a directory without changing the primary owner:
setfacl -R -m u:www-data:rwx /var/www/html
www-data user full access regardless of the file's traditional owner. ACLs are particularly useful when integrating with third-party applications that have strict permission requirements. For deeper insights into permission masks and umask issues that might interfere with these settings, refer to UMask Doesn't Change Expected Permissions in Ubuntu 24.04.
Verifying the Fix
After applying one of the above solutions, test your PHP script again. Create a simple test file containing:<?php
file_put_contents('test.txt', 'Success');
echo file_get_contents('test.txt');
?>
/var/log/apache2/error.log to ensure no further permission warnings appear. Regularly auditing these permissions helps maintain security and functionality balance.
Frequently Asked Questions
Why did changing permissions break my site?
Setting permissions too broadly, such as777, can expose your site to security vulnerabilities like code injection. Always aim for the least privilege necessary, typically 755 for directories and 644 for files, or use group-based access as described.
How do I fix permissions for a single file?
Usechmod 664 filename.php for files and chmod 775 dirname for directories. Ensure the owner is either www-data or part of the same group as www-data to allow writes.
Can I use sudo to create files in PHP?
No, you should never run PHP scripts withsudo. This bypasses security controls and can lead to severe system compromise. Instead, configure proper ownership and permissions as outlined in the solutions above.
What if I still get permission denied after changing ownership?
Check if SELinux or AppArmor is enforcing restrictions. On Ubuntu, AppArmor is default. You may need to adjust the AppArmor profile for Apache to allow writes to the specific directory path.Is it safe to give www-data ownership of all files?
It is safe for production web roots but risky for home directories. Only applychown www-data to directories served by Apache, such as /var/www, and keep your personal files under your own user account.