Enterprise Linux till version 6), others start at 1000 (Red Hat Enterprise Linux since version 7, openSUSE, Debian). On many Linux systems, these ranges are specified in /etc/login.defs, for useradd and similar tools. Central UID allocations in enterprise networks (e.g., via LDAP and NFS servers) may limit themselves to using only UID numbers well above 1000, and outside the range 60000–65535, to avoid potential conflicts with UIDs locally allocated on client computers. When new users are created locally ,the local system is supposed to check for and avoid conflicts with UID's already existing on NSS' OS-level virtualization can remap user identifiers, e.g. using Linux namespaces, and therefore need to allocate ranges into which remapped UIDs and GIDs are mapped: snapd maps UIDs and GIDs into the range 524288-589823 (0x80000-0x8ffff) systemd-nspawn automatic allocates of per-container UID ranges uses the range 524288-1879048191 (0x80000-0x6fffffff) The systemd authors recommend that OS-level virtualization systems should allocate 65536 (216) UIDs per container, and map them by adding an integer multiple of 216. Special values 0: The superuser normally has a UID of zero (0). −1: The value (uid_t) -1 is reserved by POSIX to identify an omitted argument. 65535: This value is still avoided because it was the API error return value when uid_t was 16 bits. Nobody: Historically, the user "nobody" was assigned UID -2 by several operating systems, although other values such as 215−1 = 32,767 are also in use, such as by OpenBSD. For compatibility between 16-bit and 32-bit UIDs, many Linux distributions now set it to be 216−2 = 65,534; the Linux kernel defaults to returning this value when a 32-bit UID does not fit into the return value of the 16-bit system calls. Fedora Linux assigns the last UID of the range statically allocated for system use (0–99) to nobody: 99, and calls 65534 instead nfsnobody. Alternatives NFSv4 was intended to help avoid numeric identifier collisions by identifying users (and groups) in protocol packets using textual “user@domain” names rather than integer numbers. However, as long as operating-system kernels and local file systems continue to use integer user identifiers, this comes at the expense of additional translation steps (using idmap daemon processes), which can introduce additional failure points if local UID mapping mechanisms or databases get configured incorrectly, lost, or out of sync. The “@domain” part of the user name could be used to indicate which authority allocated a particular name, for