This simple error message has causes that range from simple to sometimes pretty tricky. Most often it's that there is invisible junk on the filename, usually a newline or carriage return. Periodic reminder to include the filename in the error message to help surface such details.
$ echo foo > bar
$ echo bar | perl -e 'open $fh, "<", readline or die "err: $!\n"'
err: No such file or directory
$ echo bar|perl -e '$n=readline;open $fh,"<",$n or die "err: {$n} $!\n"'
err: {bar
} No such file or directory
Some languages or libraries may strip off the end-of-line character (or characters) for you, others may not. A hex viewer may be necessary if the invisible characters are difficult to see--zero-width spaces or other such Unicode funk come to mind.
$ make getaline
cc -O2 -pipe -o getaline getaline.c
$ echo bar | ./getaline
getaline: fopen 'bar
': No such file or directory
$ echo bar | ./getaline 2>&1 | od -bc
0000000 147 145 164 141 154 151 156 145 072 040 146 157 160 145 156 040
g e t a l i n e : f o p e n
0000020 047 142 141 162 012 047 072 040 116 157 040 163 165 143 150 040
' b a r \n ' : N o s u c h
...
However, process tracing may still be necessary, especially if it's something like a library search where the search doesn't bother to tell you what is going on, or where the documentation is poor, etc. On linux it got to the point where I would run strace or sysdig first, then maybe go look for documentation. Did what I just see in strace make sense with what the documentation (if any) says?
Systemd may create a private /tmp directory, so the /tmp/bar for one process might be unrelated to the /tmp/bar you do not see the file in. Systemd usually has pretty good documentation, and there are good reasons to have a private temporary directory. One reason is despite /tmp vulnerabilities being well known and tools available (eventually) to create files more safely under /tmp, folks continue to write /tmp vulnerabilities. OpenBSD 2.1 came out in 1997.
HISTORY
The mktemp utility first appeared in OpenBSD 2.1.
Meanwhile in 2023,
In Eternal Terminal 6.2.1, TelemetryService uses fixed paths in /tmp. For example, a local attacker can create /tmp/.sentry-native-etserver with mode 0777 before the etserver process is started. The attacker can choose to read sensitive information from that file, or modify the information in that file.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-23558
So there may be merit to a private /tmp even if it does complicate things.
Various security frameworks have been bolted onto unix over the years; these can get in the way of expected filesystem operations. unveil(2) on OpenBSD for instance can mask a process off from a file that does exist, /etc/passwd for example.
$ perl unveil.pl
err: No such file or directory
$ make wrap
cc -O2 -pipe -o wrap wrap.c
$ ./wrap
should not happen?? No such file or directory
The security team at a small internet retailer once emptied the /etc/passwd file on a bunch of systems. That was pretty fun.
Other security frameworks can do similar. SELinux too often did a great job of preventing sshd from accessing ~/.ssh/authorized_keys on RedHat Linux, for example. Is the system secure if nobody but the hackers can login to it? Sometimes the benefits/drawbacks dial needs fiddling with, especially if there is too much friction for too little benefit.
You could mount something over a file path, and probably other things I don't know about, or have forgotten about.
tags #unix