I'm running Emacs 27.2 on a Red Hat Enterprise Linux 9 virtual machine, on which I do not have admin privileges. I reach this VM either using TigerVNC or plain old SSH. This installation of Emacs apparently has some kind of permissions problem, as it can't run external programs like "ls". Here's the problem in a nutshell: In the scratch buffer, run

(executable-find "ls") ^J
(call-process "ls") ^J

So Emacs can find the executable "ls", but does not have permission to run it; hence the 126 exit code. If Emacs is started from the command line (i.e. emacs -q -no-start-init) executing (call-process "ls") generates the message "Cannot allocate memory" on the command line as well as the exit code 126.

Chasing down the executable, /bin/emacs is a link to /etc/alternatives/emacs (I think, not sure) which in turn is a link to the real executable /usr/bin/emacs-27.2, which has permissions 755. Right next to it is a file /usr/bin/emacs-27.2.pdmp, which apparently is a binary compiled from Emacs lisp code. This file has permissions 644. Both are user "root", group "root".

The sysadmins are busy/distracted/tired, don't use Emacs themselves, and asked me to run down the problem, which they appear to believe lies in the bowels of Emacs somewhere. I, OTOH, believe that this is a straightforward permissions problem that is the sysadmin's proper bailiwick.

Unfortunately, to get any response, it appears that I have to prove a negative; that is, Emacs is not the problem. So I ask you: is there any way that Emacs could be the problem?

  • Does (shell-command "ls") work?
    – shynur
    Nov 17, 2023 at 5:33
  • @shynur It behaves exactly as (call-process"ls"); exit code 126. Nov 18, 2023 at 0:29

1 Answer 1


This has nothing to do with the file permissions of the Emacs binary, that’s for sure. That just tells you who is allowed to run Emacs, nothing else. 0755 allows everyone to run it, but only root can modify the binary.

The OS is RHEL, so it has a sophisticated security system called SELinux which has fine–grained control over all aspects of the system. Run getenforce at the command line to see if it is enforcing a policy. If it is, then check /var/log/audit/audit.log to see if that policy is what is preventing Emacs from running other programs.

  • Interesting. When I ssh into the VM and type getenforce at the command line, it returns "Disabled". I don't have access to the /var/log/audit/ directory, so I can't see audit.log, but presumably that doesn't matter since no policy is being enforced. Nov 18, 2023 at 0:33
  • Yep. Maybe it really is ls just running out of memory then.
    – db48x
    Nov 18, 2023 at 0:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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