4

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.

  • 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 '18 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 '18 at 14:41
  • what about cat file_??.dat > file.dat ? – Archemar Sep 18 '18 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 '18 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 '18 at 14:46
2

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.

1

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 '18 at 16:02
  • lsattr: Permission denied While reading flags on /tmp/file_00.dat – UncaAlby Sep 18 '18 at 16:03
  • @UncaAlby try run as root – 炸鱼薯条德里克 Sep 19 '18 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 '18 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 '18 at 10:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.