I've been trying to run a command in chroot (pretty new to this), and I get the following output.

root@hostname:~ # bash <(wget -q0 https://raw.githubusercontent.com/ubports/unity8-desktop-install-tools/master/install.sh) 
bash: /dev/fd/63: No such file or directory root

TL;DR: copy the /root folder outside chroot into the chroot directory

The <(...) operator is known as process substitution and is a way to run command, output of which goes into anonymous pipe. That's what /dev/fd/63 is. The idea is to allow external command ( here it's bash ) to treat another commands output as if it was a file. Generally the form would be to use < to redirect that pseudo-file object into bash's input stream.

bash < <(wget -q0 https://raw.githubusercontent.com/ubports/unity8-desktop-install-tools/master/install.sh)

This is generally no different from wget https://stuff.com/blah | bash. In both cases, it's generally not recommended to use such commands unless you're hundred percent sure the script you're downloading isn't from sketchy source and isn't malware.

However, since you've mentioned running command in chroot and the script outputs No such file or directory root, and because bash allows running scripts as bash script.sh here your script is being executed, but there's no directory named root in your chroot. You could just fix it via sudo cp -R /root chrootdir. For better results I'd suggest just reading the script first, see what it needs, and copy that to the chroot folder, and only then run the script locally within the folder. No need to run wget multiple times

So the script works. Errors in shell scripting generally in form <shell>: <command user typed>: error message so the script being temporarily stored as /dev/fd/63 and runs, it just doesn't find what it needs.

See also,

  • 1
    Seems to have worked. Thanks. Also, the script is legitimate, and is just to try some stuff in a VM, anyhow, so no security risk.
    – Radu
    Oct 24 '18 at 9:55

Error message

/dev/fd/63 No such file or directory

Problem source

Indeed the directory /dev/fd/ did not exist on that machine.


The solution was to create a symbolic link from /proc/self/fd to /dev/fd like so:

ln -s /proc/self/fd /dev/fd

Process substitution <(..) wouldn't work on QNAP without this.

  • Please provide answers in the context ... Why do you mention "if you are coming from search engine" ?
    – jmary
    Jun 16 '20 at 9:27
  • I updated my answer. why did you minus 1 my answer? I think this addition will help people in the future Jun 16 '20 at 10:23
  • Because "the mention if you are coming from search engine" doesn't make sense in context. Also you provide a "magic" command which is writting into a system directory without explaining why it is safe to do this. Sorry I don't mean to be rude. Please edit your reply so that newbies can use what you explain with confidence.
    – jmary
    Jun 16 '20 at 13:01
  • You are being rude but at least your second message was constructive. Is my answer better now? I believe a newbie doesn't mess with process substitution. Jun 16 '20 at 14:43
  • to add more on my previous comment, I believe the mention "if you are coming from a search engine" does put things in context. My message applies in a different context than the original question. no chroot here Jun 17 '20 at 7:32

I recently faced the same problem, but then I realized that it only happens if you run with sudo/root user.

If I run:

sudo bash <(echo "It worked")

I get:

bash: /dev/fd/63: No such file or directory

But if I run:

bash <(echo "It worked")

It works just fine.


Just had this exact thing happen to me. Turns out;

SSH through VSCode Terminal (or PowerShell/PSCore) don't like doing this. When I SSH'd through PUTTY everything went well.

The more you know, I guess~

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.