---
name: "netgroup"
section: "5"
platform: "freebsd"
package: "base"
version: "16.0-CURRENT-20261027-61c70dc16a79"
release: "FreeBSD 16.0-CURRENT (2026-10-27)"
platforms: ["linux", "freebsd", "openbsd", "macos"]
url: "https://new.carta.tech/netgroup/5"
---

# netgroup(5)

defines network groups

## NAME

**netgroup** – defines network groups

## SYNOPSIS

**netgroup**

## DESCRIPTION

The **netgroup** file specifies \`\`netgroups'', which are sets of **(host,** **user,** **domain)** tuples that are to be given similar network access.

Each line in the file consists of a netgroup name followed by a list of the members of the netgroup. Each member can be either the name of another netgroup or a specification of a tuple as follows:

```
(host, user, domain)
```

where the **host**, **user**, and **domain** are character string names for the corresponding component. Any of the comma separated fields may be empty to specify a \`\`wildcard'' value or may consist of the string \`\`-'' to specify \`\`no valid value''. The members of the list may be separated by whitespace and/or commas; the \`\`\\'' character may be used at the end of a line to specify line continuation. Lines are limited to 1024 characters. The functions specified in [getnetgrent(3)](/getnetgrent/3.md) should normally be used to access the **netgroup** database.

Lines that begin with a # are treated as comments.

## NIS/YP INTERACTION

On most other platforms, **netgroup**s are only used in conjunction with NIS and local */etc/netgroup* files are ignored. With FreeBSD, **netgroup**s can be used with either NIS or local files, but there are certain caveats to consider. The existing **netgroup** system is extremely inefficient where **innetgr**(*3*) lookups are concerned since **netgroup** memberships are computed on the fly. By contrast, the NIS **netgroup** database consists of three separate maps (netgroup, netgroup.byuser and netgroup.byhost) that are keyed to allow **innetgr**(*3*) lookups to be done quickly. The FreeBSD **netgroup** system can interact with the NIS **netgroup** maps in the following ways:

- If the */etc/netgroup* file does not exist, or it exists and is empty, or it exists and contains only a ‘+’, and NIS is running, **netgroup** lookups will be done exclusively through NIS, with **innetgr**(*3*) taking advantage of the netgroup.byuser and netgroup.byhost maps to speed up searches. (This is more or less compatible with the behavior of SunOS and similar platforms.)

- If the */etc/netgroup* exists and contains only local **netgroup** information (with no NIS ‘+’ token), then only the local **netgroup** information will be processed (and NIS will be ignored).

- If */etc/netgroup* exists and contains both local netgroup data *and* the NIS ‘+’ token, the local data and the NIS netgroup map will be processed as a single combined **netgroup** database. While this configuration is the most flexible, it is also the least efficient: in particular, **innetgr**(*3*) lookups will be especially slow if the database is large.

## FILES

- */etc/netgroup*

  the netgroup database

## COMPATIBILITY

The file format is compatible with that of various vendors, however it appears that not all vendors use an identical format.

## SEE ALSO

[getnetgrent(3)](/getnetgrent/3.md), [exports(5)](/exports/5.md)

## BUGS

The interpretation of access restrictions based on the member tuples of a netgroup is left up to the various network applications. Also, it is not obvious how the domain specification applies to the BSD environment.

The **netgroup** database should be stored in the form of a hashed [db(3)](/db/3.md) database just like the [passwd(5)](/passwd/5.md) database to speed up reverse lookups.