After a server reboot, PHP (php-fpm) suddenly seems unable to write to /home, basically breaking every website. PHP 7.2, 8.1 and 8.2 are installed. The systemd services don't have ProtectHome or ProtectFull in them. No upgrade of any kind was run before reboot, however apt-get upgrade runs regularly on a cron job. Any ideas?
PHP can't write to /home after reboot (read-only file system)
- Thread starter Protected
- Start date
Richard G
Verified User
I presume you do not have mod_ruid2 enabled in the custombuild options.conf file?
Do the php-fpm logfiles say anything specific?
Check if /home is owned by root and chmod 755.
Check in /home if the users home directory's are either owned by user:admin (admins), user:access (resellers) or user:user (users).
Do the php-fpm logfiles say anything specific?
Check if /home is owned by root and chmod 755.
Check in /home if the users home directory's are either owned by user:admin (admins), user:access (resellers) or user:user (users).
Richard G
Verified User
Additionally, if it's really read-only filesystem (I missed that a moment ago) then it most likely is a filesystem issue.
Try to check your file systems with a command like this:
Use this command to check all filesystems:
Or otherwise see if you can boot into a safe mode and access via KVM or something and check like this.
ofcourse replace with the correct filesystem and disk.
Try to check your file systems with a command like this:
Use this command to check all filesystems:
sudo fsck -Af -MOr otherwise see if you can boot into a safe mode and access via KVM or something and check like this.
sudo fsck.ext4 -f /dev/sda1ofcourse replace with the correct filesystem and disk.
SimpleSonic
Verified User
- Joined
- Dec 22, 2022
- Messages
- 23
Is it only /home that is read-only? Or is it the entire file system?
I only have evidence of /home having this issue. Consider that /home is its own partition. I was already trying to reboot to recovery for a filesystem check, except it seems my hosting provider is now only offering access to recovery via IPv6 and I don't have a working IPv6 route from here (unless I tunnel through the server, which... well, you know). So I'm wrestling with that right now. Oof.
SimpleSonic
Verified User
- Joined
- Dec 22, 2022
- Messages
- 23
I have to ask, since /home is on it's own partition, you did make sure you have adequate disk space available on that partition, correct?
There is more than 1.5TB of free space in that partition. Thanks for asking though. This is also not a new system. It was set up years ago and has been running smoothly since the latest OS upgrade, to Debian Bullseye, several months ago.
mod_ruid2=no in options.conf . What difference would that make?
Nothing of note in php-fpm.log . Says it's ready to handle connections (all three versions).
/home is owned by root:root and 755
User homes are owned by user:access .
I think I got ipv6 to work, I'll also try rescue again.
mod_ruid2=no in options.conf . What difference would that make?
Nothing of note in php-fpm.log . Says it's ready to handle connections (all three versions).
/home is owned by root:root and 755
User homes are owned by user:access .
I think I got ipv6 to work, I'll also try rescue again.
SimpleSonic
Verified User
- Joined
- Dec 22, 2022
- Messages
- 23
Running fsck as previously suggested would definitely be a good starting point.
I ran fsck on the /, /home and /tmp partitions in recovery. It found some errors but seemed minor (unoptimized trees and slightly incorrect block and inode counts).
php (fpm)'s inability to write to files persists after reboot.
Command line php, when executed by the same user accounts, can write to files in the same paths with no issues.
php (fpm)'s inability to write to files persists after reboot.
Command line php, when executed by the same user accounts, can write to files in the same paths with no issues.