Yum Error: unpacking of archive failed on file /var/log/httpd: cpio: lsetfilecon

Recently, I was running “yum update” on a Oracle Linux 7 system, and all the updates succeeded except for httpd, which is for Apache.

Upon researching this error, the most obvious solution was from RedHat at https://access.redhat.com/solutions/2934551. Unfortunately RedHat blocks reading the solutions without a paid or developer account. I had to research further.

I received in error in the yum output which reminded me of SELinux related errors:

Error unpacking rpm package httpd-2.4.6-97.0.7.el7_9.5.x86_64
error: unpacking of archive failed on file /var/log/httpd: cpio: lsetfilecon
httpd-2.4.6-97.0.5.el7_9.5.x86_64 was supposed to be removed but is not!

The part of the error that reminded me of SELinux was “lsetfilecon“. In SELinux, every file on the filesystem is labeled with a corresponding security context, stored in extended filesystem attributes. Upon researching this, I found that lsetfilecon is a C function in the SELinux API. We can read information about this function by typing “man 3 lsetfilecon” in a terminal on Linux (the 3 indicates C functions from the Linux Programmer’s Manual):

DESCRIPTION
setfilecon() sets the security context of the file system object.

lsetfilecon() is identical to setfilecon, except in the case of a symbolic link,
where the link itself has it’s context set, not the file that it refers to.

So apparently, yum could not set the security context of the folder /var/log/httpd. Having this information, I attempted to manually set the context of this folder using “restorecon -RvF /var/log/

Immediately, errors came across that indicated there was no more space left on the /var/log partition:

restorecon reset /var/log/spooler-20220724 context unconfined_u:object_r:var_log_t:s0->system_u:object_r:var_log_t:s0
restorecon set context /var/log/spooler-20220724->system_u:object_r:var_log_t:s0 failed:’No space left on device’
restorecon reset /var/log/grubby context unconfined_u:object_r:var_log_t:s0->system_u:object_r:var_log_t:s0
restorecon set context /var/log/grubby->system_u:object_r:var_log_t:s0 failed:’No space left on device’
restorecon reset /var/log/grubby_prune_debug context unconfined_u:object_r:var_log_t:s0->system_u:object_r:var_log_t:s0
restorecon set context /var/log/grubby_prune_debug->system_u:object_r:var_log_t:s0 failed:’No space left on device’
restorecon reset /var/log/spooler-20220717 context unconfined_u:object_r:var_log_t:s0->system_u:object_r:var_log_t:s0
restorecon set context /var/log/spooler-20220717->system_u:object_r:var_log_t:s0 failed:’No space left on device’
restorecon reset /var/log/nginx/access.log-20220702.gz context unconfined_u:object_r:httpd_log_t:s0->system_u:object_r:httpd_log_t:s0
restorecon set context /var/log/nginx/access.log-20220702.gz->system_u:object_r:httpd_log_t:s0 failed:’No space left on device’
restorecon reset /var/log/nginx/error.log-20220702.gz context unconfined_u:object_r:httpd_log_t:s0->system_u:object_r:httpd_log_t:s0

Then, I ran “df -h” and saw the /var/log partition was maxed out at 100% utilization:

  Filesystem                      Size  Used Avail Use% Mounted on
devtmpfs                        1.8G  4.0K  1.8G   1% /dev
tmpfs                           1.8G  8.0K  1.8G   1% /dev/shm
tmpfs                           1.8G  201M  1.6G  12% /run
tmpfs                           1.8G     0  1.8G   0% /sys/fs/cgroup
/dev/mapper/system-fsroot       8.0G  7.3G  712M  92% /
tmpfs                           2.0G  540K  2.0G   1% /tmp
/dev/mapper/system-home         4.0G  3.0G 1018M  76% /home
/dev/mapper/system-var           64G   18G   47G  28% /var
/dev/mapper/system-vartmp       2.0G  897M  1.2G  44% /var/tmp
/dev/mapper/system-varlog       6.0G  6.0G   20K 100% /var/log

I looked in /var/log and found 4 old /var/log/messages rotated log files that were taking up 1.5G a piece. After deleting these, the yum update command ran and had no errors relating to setting SELinux context.

Apparently if the disk space has been maxed out, you cannot set SELinux attributes on those files.

This was a simple solution, I couldn’t find many results searching for this error that were directly applicable to my issue so I decided to share it to hopefully save someone else some time, as the error does not immediately indicate it is a storage space issue.