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, 2015 at 10:38
  • 3
    Did you try to reinstall iputils-ping ? Jun 3, 2015 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, 2015 at 11:30

3 Answers 3


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, 2015 at 8:36
  • @FalconMomot, I appended the solution. Nov 9, 2015 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, 2020 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, 2020 at 1:53
  • reinstalling did the trick for me! You have to explicitly remove it, 'apt remove iputils-ping' and install it again with 'apt install iputils-ping' Jul 28, 2022 at 1:54

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, 2015 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, 2019 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, 2018 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, 2018 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, 2018 at 15:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .