I am running a vserver environment with several virtual machines. A single VM has the following problem:

$ ping
ping: icmp open socket: Operation not permitted

$ ls -l $(which ping)
-rwsr-xr-x 1 root root 30736 2007-01-31 00:10 /bin/ping

$ whoami

$ mount
/dev/hdv1 on / type ufs (defaults)
none on /proc type proc (0)
none on /tmp type tmpfs (size=16m,mode=1777)
none on /dev/pts type devpts (gid=5,mode=620)

$ uname -a
Linux v-web1 #1 SMP Tue Apr 28 11:35:00 CEST 2015 i686 GNU/Linux

Note that on the host machine as well as on all other VM hostet there, Ping works fine.

Does anyone have any idea to help me, please?

  • Is /bin/ping set-uid on the other machines? Is TCP/IP correctly set up on this VM? Do other things work like DNS, traceroute, HTTP? Jun 3 '15 at 10:38
  • 2
    Did you try to reinstall iputils-ping ? Jun 3 '15 at 10:42
  • Another information may be useful: This is a highly productive machine running Apache with about 5 to 7 accesses per second - so no idea about modifying the network configuration. It has moved to a new hardware last night, and since then, Munin shows that Ping ain't working. Jun 3 '15 at 11:30

TL;DR version: reinstall iputils-ping

I have seen online where it has been suggested to use

chmod u+s $( which ping );

However this will permit the user to change the preload and flood. Which could result in a USER being able to Denial Of Service either your local machine or another machine or your network.

I tried what @nabil-bourenane suggested, reinstalling iputils-ping which resolved the issue for me and doesn't have the SUID bit set.

username@server:~$ ls -l $( which ping );
-rwxr-xr-x 1 root root 44104 Nov  8  2014 /bin/ping

If the SUID bit is set it will look like

username@server:~$ ls -l $( which ping );
-rwsr-xr-x 1 root root 44104 Nov  8  2014 /bin/ping
  • 1
    If you're already root, SUID root binaries won't change much. Aug 31 '15 at 8:36
  • @FalconMomot, I appended the solution. Nov 9 '15 at 8:06
  • Reinstalling iputils (same version before/after) worked for me on centos7. Before, getcap /bin/ping showed no capabilities set. After reinstall, getcap /bin/ping returned: /bin/ping = cap_net_admin,cap_net_raw+p. Now the question is: why it lost the capabilities. rpm --verify iputils did show that ping, arping and clockdiff all showed that the cap settings had changed (before the reinstall).
    – Juan
    Jan 31 '20 at 1:34
  • In my case, it may have lost file capabilities after a restore from a dump image. See also unix.com/unix-for-advanced-and-expert-users/…. In that case, they used tar. In my case, I was hoping dump/restore preserved all those file attributes (attrs, capabilities, acls, etc.). I'm surprised it didn't, so I'll have to see if I can reproduce it (and then maybe log a bug).
    – Juan
    Jan 31 '20 at 1:53

The solution is to set Linux System Capabilites to allow raw socket on the host machine.

Since this is a very v-server specific problem, the solution is to create a single-lined file named /etc/vservers/VMNAME/bcapabilities:


and reboot VM.

  • 1
    "And how do you accomplish this?" would be useful as a complete answer.
    – ILMostro_7
    Nov 7 '15 at 1:21
  • After 4 years, I changed the accepted answer to mine, because it REALLY ANSWERS THE QUESTION. This is v-server problem and has nothing to do with the file mode of the ping executable. May 17 '19 at 7:32

Sorry I can't comment. This problem hit me after I extracting an archive of a working system over a minimal installation.

All above answers work. But the one proposed by @Nabil Bourenane and @Linx is prefered for security. To answer @rexkogitans's comment, here I quote from iputils-ping.postinst (/var/lib/dpkg/info/...)

if command -v setcap > /dev/null; then
    if setcap cap_net_raw+ep /bin/ping; then
        chmod u-s /bin/ping
        echo "Setcap failed on /bin/ping, falling back to setuid" >&2
        chmod u+s /bin/ping
    echo "Setcap is not installed, falling back to setuid" >&2
    chmod u+s /bin/ping

which basically says when configuring iputils-ping, first try setcap then if that fails use chmod u+s. That's why reinstalling iputils-ping works.

  • 1
    So this will work: setcap cap_net_raw+ep /bin/ping
    – rlf
    Jun 5 '18 at 21:39
  • It was not my comment, but my answer to my own question. The problem cannot be solved from within the container, so whatever the post install hook does is pointless. Jun 6 '18 at 10:03
  • 1
    Indeed, setcap cap_net_raw+p $(which ping) as root fixes it. There is a thorough explanation on this blog post: Linux Capabilities and Ping
    – mivk
    Oct 6 '18 at 15:08

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.