Permissions denied on files despite 777 mode

Question

I am getting a permission denied error on CentOS 6.10 64 bit

Kindly note that the "#" indicates a Root Level User prompt.

# cd /tmp
# chmod 777 file*
# /bin/ls -l file*
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_00.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_01.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_02.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_03.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_04.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_05.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_06.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_07.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_08.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_09.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_10.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_11.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_12.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_13.dat
-rwxrwxrwx 1 apache apache   824 Sep 17 17:15 file_14.dat
-rwxrwxrwx 1 apache apache     1 Sep 17 17:15 file_15.dat
# cat file* > file.dat
cat: file_00.dat: Permission denied
cat: file_02.dat: Permission denied
# /bin/ls -l file.dat
-rw-rw-r-- 1 root   root   10713 Sep 17 17:32 file.dat

The size of the full file is 10713, which is 824*13+1, meaning it was, successfully, copied every file except the files "00" and "02". A successful copy should be 12361 bytes, 824*15+1. However, there is nothing different about these two files, except that the machine refuses to let me read them.

The command "chmod 777" is redundant, just to emphasize the situation. Before running that command, permissions were all in the form "-rw-r--r--", which still means that I should not be getting a permission denied error.

There is no "." on the permissions, so theoretically, Selinux should not be involved, but even if it is involved, why is it only picking on just two files?

I can repeat the process that creates these files, and it will choose a different set of files to be unreadable. Does anybody have an explanation and fix for this?

UPDATE:

I have modified the process that creates the files. Previously it was receiving the data from a JavaScript client that broke an XLSX file into chunks to allow uploading spreadsheets of massive size. The server would receive the chunks as base64, decode each chunk to binary, then save it in a temporary file to be concatenated into a final XLSX file.

What it does now is save each temporary chunk as base64 (100% ASCII). Once all the chunks are uploaded, it reads each file, then decodes it to binary, and appends it to the final XLSX file.

Works fine. I think we'll leave it that way.

As a test, I wrote a quick 3 line program to read one of the base64 chunks, decode it to binary, then save it. Then I tried to read result. Guess what? Permission denied on the binary file.

So apparently, what makes the file unreadable is some pattern of data inside the file.

Using this method resolves the issue, but I still would like to know how a pattern of binary data inside a file creates a "Permission denied" error on the outside.

Answer 1

FINAL UPDATE

Turns out our service provider had a Red-Hat Linux anti-virus program running. Which, obviously, I was unaware of.

Turn off the anti-virus, and all files magically become readable. Turn it back on, and a certain select few of the files happen to match some virus signature.

The anti-virus should be on the look-out for executable files. (the files were originally mode 644 when the problem surfaced)

There should be different error message.

Oh well. Henceforth we will encode the files in Base64, problem solved.

Thanks again to all who helped.

Answer 2

It might be a file attribute has been set. Try to list with lsattr command. Then you can unset with the activr attributes with chattr -[acdeijstuADST] filename.

You can find more info at man chattr.