[Note: This similar Q concerns the same bash error message. It's been marked a duplicate of this other Q. But because I found a very different source for this error, I will answer my own Q below.]

This previously working bash script line

while ... do ... done <<< "$foo"

one day started producing this error message:

cannot create temp file for here-document: Permission denied

  • In my case it was enabled IMA (ima_policy=appraise_tcb kernel parameter) with combination of /tmp not being tmpfs. But this is not really a common case :).
    – pevik
    Jun 3 '19 at 16:04

I had added umask 777 before the here string. After removing the umask, the error went away. So lesson learned: There is a temporary file created for a here string (<<<), and this is related to a here document (<<), and you must have an appropriate umask set for these to work.

  • Interesting indeed. +1 See unix.stackexchange.com/questions/166292/… Mar 9 '18 at 16:35
  • It also affects zsh and mksh, not ksh93 nor tcsh. Not dash, rc, es, nor yash either but that's because they use pipes instead of temp files. Mar 9 '18 at 17:45
  • In the case of ksh93 and tcsh, it works because they open the file only once in read+write mode, write the data and then seek back to the beginning. Mar 9 '18 at 17:55

In my case I altered the /tmp directory default permissions (I think I've changed by mistake to 0777).

The solution was to revert it back to the default /tmp permission, which is 1777 in octal (1=sticky bit, 7=R+W+X).

So in a nutshell sudo chmod -R 1777 /tmp should fix the problem.

  • I can see where that would indeed cause issues. Yes, the sticky bit is important for /tmp. Apr 8 '18 at 14:21
  • 2
    You probably don't want the -R flag. No reason to change everyone's files below /tmp to be read-write-executable by everyone. Some of those files are sensitive to the security of your users. Apr 3 '19 at 11:31

my personal experience with this problem was with umask binary notation, just like @eliptical-view. I supposed that writing:

umask 0644 

would give me read and write access to the files I created, what's wrong

After I changed the umask to be

umask 0022

the error disappeared.

Actually, the binary notation should be understood as a binary complement.

So, in the umask's mask below when one writes 0 for the file owner, this user will have total access to the files he or she creates. The value 2 means the 2nd bit is masked, what means in this case, by default the other users will not be allowed to write to the files the file owner creates.

  • 1
    Thanks for the edit and correction, @Paulo Tomé. Indeed, it is usual (and clear) to use octal notation in umask, for precisely three bits are involved in Posix file permissions -- for the owner, one of his or her groups, and everybody else. Mar 5 '20 at 17:34
  • You're welcome. ;) Mar 5 '20 at 17:36

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.