I am trying to set samba context on directory with following command and I am not sure what this error is about but I can not set the context on directory.

semanage fcontext -a -t samba_share_t "/common(/.*)?"

error Thrown as follows:

Full path required for exclude: net:[4026532292].

2 Answers 2


It's been over a year since this was asked, but I didn't find an answer online. Let's fix that for the next person. :)

Those errors occur because something has created network namespaces on your machine. If you look at the output of mount you'll see a proc filesystem type mounted somewhere (probably under /run or /var/run) with that number. However, if you look at /proc/mounts like restorecon (and semanage) does, you'll see the same filesystem with "net:[xxx]" as the mount point. Unfortunately, restorecon / semanage have no idea how to deal with that; they just see a path which doesn't start with a / and emits an error.

Why does it do that? If you check out the restorecon source, you'll see that restorecon automatically adds exclude entries for mountpoints which don't have the seclabel mount option set. Same presumably goes for semanage. The seclabel option should be managed by SELinux, I think. What it does is indicates that the filesystem uses xattrs to store the SELinux attributes. That's why those filesystems are being excluded: it doesn't make sense to try to set the context on files when the filesystem doesn't support SELinux contexts.

Great. How do you fix it? The selinux_restorecon() syscall includes a flag - SELINUX_RESTORECON_IGNORE_MOUNTS - which instructs it to not bother with that check, but there doesn't seem to be a way to tell the restorecon or semanage programs to do the same. So, one option is to write your own restorecon program which makes that syscall with the flag to ignore mount labels. That's a pain. :) An easier option I like is to just use a mount context to hide those mount points you're probably not interested in traversing anyway. Contexts cause the problem, so why not fix it with contexts too?

sudo unshare -m sh
umount $( mount | awk '$3~/netns/{print $3}' )
restorecon -rv /some/file

Use unshare -m to create a new mount namespace and run sh (pick your favorite shell here) in that namespace. Then unmount the offending filesystems. In my case with Docker doing this, the filesystems all include netns (and I have no filesystems with that string), so I just pull the matching mountpoints out and pass those to umount. Someone else might need to find and unmount differently, but the idea is the same. Because unshare -m defaults to a private mount namespace, the unmounting doesn't impact anything else on the system - it basically hides the mounts from this process. At that point, I have a shell where those filesystems are not visible. So, when restorecon inspects /proc/self/mounts (it technically opens /proc/mounts, but for backwards compatibility that's a link to /proc/self/mounts on systems which support mount namespaces) in the namespace it inherits from the shell, it's able to run with no problems.

If you find yourself doing this often, it would probably make sense to put the umount and restorecon into a shell script and just run that with restorecon instead of starting a shell.

  • Suddenly nginx stopped being able to access my config while the sudo -u nginx namei -om on it works fine. I've discovered that the selinux is Enforcing and tried to run this command as someone proposed in another question but it gives this error as OP here has. But my config has nothing to do with volumes -- it's a symlink leading to user home dir that is on the main drive.
    – Nakilon
    Feb 20, 2020 at 2:28
  • You could conceivably be getting a similar message re "full path required" due to a dangling or relative symlink, @Nakilon, but the critical piece leading to this specific question is the net: in the output. If you don't see net:[ in your error message, your issue is something else; something different enough that it probably justifies a new question. :) If you do see that, then the symlink is ancillary to the real problem.
    – dannysauer
    Feb 20, 2020 at 21:32
  • 1
    I fixed my issue -- it was about adding -F flag to restorecon. The :net error still prints but it is not a problem. Also I had to run setsebool -P httpd_can_network_connect 1 in my case. Seems like selinux somehow enabled itself on my server during last weeks. I disabled it globally back in 2016 and nginx was restarting fine but now nginx -t said it's ok but when I restarted it it was unable to read my configs.
    – Nakilon
    Feb 21, 2020 at 3:32

The error you see is not caused by applying samba_share_t context on /common directory. You can still try restorecon -R /common, and check selinux context is indeed changed. I believe the error originates from previous configurations.

  • 1
    Hi, restorecon eventually works but i would like understand why that error is thrown. What could be the possible miss configuration causing those errors.
    – Sagar
    Jul 10, 2016 at 7:45

You must log in to answer this question.

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