19

[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

JoL
  • 4,735
Elliptical view
  • 3,921
  • 4
  • 27
  • 46
  • 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 03 '19 at 16:04

3 Answers3

14

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.

Eugen Mihailescu
  • 241
  • I can see where that would indeed cause issues. Yes, the sticky bit is important for /tmp. – Elliptical view Apr 08 '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. – keithpjolley Apr 03 '19 at 11:31
12

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.

Elliptical view
  • 3,921
  • 4
  • 27
  • 46
  • Interesting indeed. +1 See https://unix.stackexchange.com/questions/166292/bash-cannot-create-temp-file-for-here-document-no-space-left-on-device/166295 – Rui F Ribeiro Mar 09 '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. – Stéphane Chazelas Mar 09 '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. – Stéphane Chazelas Mar 09 '18 at 17:55
2

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.

Paulo Tomé
  • 3,782
Hilton Fernandes
  • 121
  • 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. – Hilton Fernandes Mar 05 '20 at 17:34
  • You're welcome. ;) – Paulo Tomé Mar 05 '20 at 17:36