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?


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.

  • Thanks for your response, @Goro. It's a headless server, no GUI, but I've tried "less", "more", and "vim" with the same Permission Denied error. The only thing I've been able to do is "mv" and "rm", but of course those affect the containing directory, not the file itself.
    – UncaAlby
    Sep 18, 2018 at 14:38
  • There are two pints here. Either the files were not copied correctly, or it is indeed a permission issue. for the later try chmod 700 and see. You have to open the files to see if they were copied correctly!
    – user88036
    Sep 18, 2018 at 14:41
  • what about cat file_??.dat > file.dat ?
    – Archemar
    Sep 18, 2018 at 14:41
  • Thanks for your response, @Archemar -- Permission Denied on each file with a permission error, and each of the other files is copied successfully. Same result as cat file_* > file.dat
    – UncaAlby
    Sep 18, 2018 at 14:44
  • I remember if it has selinux context ls will show a Z flag at the end of output. So…check ls again? Is some other process running affecting these files? Sep 18, 2018 at 14:46

2 Answers 2



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.

  • How does the antivirus hook into the system to not allow files to be erased? Oct 20, 2021 at 17:01
  • @placidchat You will need to contact a Linux antivirus company with that question. All I know is, the antivirus thought the upload matched a virus signature, so therefore it locked it down.
    – UncaAlby
    Oct 23, 2021 at 18:49
  • I think they're using ebpf to insert pattern matching checks into open streams Oct 29, 2021 at 3:46

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.

  • Thanks for your respons, @affan -- no bueno.
    – UncaAlby
    Sep 18, 2018 at 16:02
  • lsattr: Permission denied While reading flags on /tmp/file_00.dat
    – UncaAlby
    Sep 18, 2018 at 16:03
  • @UncaAlby try run as root Sep 19, 2018 at 0:38
  • @神秘德里克 -- I run using "sudo bash" which as close to root as I'm allowed, and until now, was all the root I ever needed. As far as I know, it's the same as logging in directly as root, except my access is logged somewhere for audit. More importantly, the process that creates the files and will ultimately need to read them is run by user "apache" and I don't think I want to change that.
    – UncaAlby
    Sep 19, 2018 at 1:24
  • Maybe it is locked by some process, can you try again with lsof file_00.dat. Or lslk or lslocks?
    – affan
    Sep 19, 2018 at 10:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .