If you’ve come here looking to fix an errant recursive chmod or chown command on an RPM-based Linux system, then here is the quick solution. Run the following commands using root privileges:
rpm --setugids -a
rpm --setperms -aThe --setugids option to the rpm command sets user/group ownership of files in a given package. By using the -a option we’re telling rpm to do this on all the packages. The --setperms option sets the permissions of files in the given package.
If this fixes your issue, great! If not, or you want to be thorough, continue reading.
Why Would You Need To Fix the Permissions and User/Group Ownership of Files
The most common reason you’ll need to follow the procedure below is to recover from a chmod or chown command that didn’t do what you initially intended it to do. Using this procedure can save you from having to perform a complete system restore or a complete system reinstall.
In any case, perhaps someone else accidentally executed a recursive chmod or chown command on part or even the entire file system. Even if the mistake is noticed and the command is stopped by typing Control-C as quickly as possible, many files could have been changed in that short period of time, and you won’t be able to immediately tell which files were changed.
Problems Caused by Incorrect Permissions and Ownerships of Files
Having improper file permissions or ownerships can cause processes and services to behave in unexpected ways, stop working immediately, or prevent them from starting once they’ve been stopped.
For example, if the user running the web server process can’t read the files it’s supposed to serve, then the service it provides is effectively broken.
If a service is already running, it probably doesn’t need to read its configuration file(s) again as it has that information in memory. However, if it can’t read its configuration when it attempts to start, it simply isn’t going to start.
Also, when some services start, they create a lock file to indicate that the service is running. When the service stops, it deletes the lock file. However, if the permissions on that lock file are changed while the service is running such that the service can’t delete the file, then of course the lock file won’t get deleted. This will prevent the service from starting again, as it thinks it’s already running due to the presence of the lock file.
Perhaps the file that actually needs to be executed no longer has execute permissions. Needless to say, that will definitely keep a service from starting.
If you have a service such as a database that writes data, it needs the proper permissions to write data to a file, create new files, and so on.
Those are some common issues you can run into when file permissions and ownerships are not set properly.
Examples of Errant chmod and chown Commands
A common way a chmod or chown command can go wrong is by using recursion while making a typing mistake or providing an incorrect path. For example, let’s say you’ve created some configuration files in the /var/lib/pgsql directory as the root user. You want to make sure all those files are owned by the postgres user, so you intend to run this command:
chown -R postgres /var/lib/pgsqlHowever, you accidentally add a space between the leading forward slash and var, making the actual command executed this one:
chown -R postgres / var/lib/pgsqlOh, what a difference a space can make! Now, every file on the system is owned by the postgres user.
The reason is that chown rightly interpreted the first forward slash ( “/” ) as an absolute path to operate upon and “var/lib/pgsql” as a relative path to operate on. The chown command, and any Linux command for that matter, only does what you tell it to do. It can’t read your mind. It doesn’t know that you intended to only supply the one path of /var/lib/pgsql.
Fixing File Ownerships and Permissions with the RPM Command
Continuing with our example, you should be able to execute the following command with root privileges and return to a fairly stable state:
rpm --setugids -aThis command will return the owner and group membership for every file that was installed via an RPM package. Changing the ownership of a file can cause the set-user-ID (SUID) or set-group-ID (GUID) permission bits to be cleared. Because of this, we need to restore the permissions on the files as well:
rpm --setperms -aNow, every file that is known by rpm will have the same permissions as when it was initially installed.
By the way, use this same process to fix an errant chmod command, too. Be sure to use the same order of the commands due the SUID and GUID issues that could arise. IE, run rpm with the --setperms options last.
Fixing File Ownerships and Permissions for Files Not Known by RPM
Not all the files on the system are going to be part of an RPM package. Most data, either transient or permanent, will live outside an RPM package. Examples include temporary files, files used to store database data, lock files, website files, some configuration files, and more depending on the system in question.
At least check the most important services that the system provides. For example, if you are working on a database server, make sure the database service starts correctly. If it’s a web server, make sure the web server service is functioning.
Here is the pattern:
systemctl restart SERVICE_NAMEIf the service does not start, determine the reason by looking at the logs and messages:
journalctl -xeFix any issues and try again until the service starts.
Example:
systemctl restart postfix
# The service fails to start.
journalctl -xe
# The error message is “fatal: open lock file /var/lib/postfix/master.lock: cannot open file: Permission denied”
# Fix the obvious error.
rm /var/lib/postfix/master.lock
# Make sure there aren't other files that may have permissions or ownership issues in that directory.
ls -l /var/lib/postfix
# There are no other files.
# Try to start the service again.
systemctl start postfix
# No errors are reported. The service is working! Lets double-check:
systemctl status postfixYou can check which services are in a failed stated by using the following command.
systemctl list-units --failedLet’s say you reboot the system and want to make sure everything started ok. Then run the above command and troubleshoot each service as needed.
Also, if you have good service monitoring in place, check there. Your monitors should report if any service isn’t functioning appropriately and you can use this information to track down issues and fix them as needed.
A List of Directories that Are Not in the RPM Database
Here are some common places to look for files that live outside an RPM package:
/var/log/SERVICE_NAME/ (Example: /var/log/httpd) /var/lib/SERVICE_NAME/ (Example: /var/lib/pgsql) /var/spool/SERVICE_NAME/ (Example: /var/spool/postfix) /var/www /usr/local /run /var/run/ /tmp /var/tmp /root /home
Correcting Home Directory Ownership
If user home directories were changed do to a recursive chmod or chown command, then they need to be fixed. If the ownership has changed, we can make an assumption that each home directory and all of its contents should be owned by the corresponding user. For example, “/home/jason” should be owned by the “jason” user and any files in “/home/jason” should be owned by the “jason” user, too. Here’s a quick script to make this happen:
cd /home
for U in *
do
chown -R ${U} ${U}
doneBe careful with the chown command because we don’t want to create another mess!
It could be the case that some files in a given home directory should not be owned by the user. If you think this might be the case, your best course of action is to restore the home directories from backups. Speaking of which…
Why Not Just Restore from Backup?
If you have a good and recent backup, restoring that backup might be a great option. If the server in question doesn’t actually store data, then it would be a perfect candidate for a restore, as you won’t lose any data.
Performing a restore can give you the peace of mind that all the files on the system have the proper permissions and ownership. After you’ve rigorously checked the services, the chances of any missed files causing operational issues is low. Nevertheless, there is a possibility of an issue arising at a later date. A restore reduces this probability even further.
You could also use a hybrid approach, where you run through the above process and selectively restore parts of the system.
The downside of performing a restore is that it can be slower than using the process outlined above. It’s much quicker to change the permissions on a 1 TB file than it is to restore that file.
Of course, if you don’t have a backup that you can restore then you will have to follow a process like the one outlined above.