SUMMARY: if UID > 9999999 then quota is DRUNK!

From: Marcelo Maraboli (
Date: Fri Aug 22 1997 - 15:11:56 CDT

hello folks..

well...i got many answers and a solution!..

the problem was...

> hello admins..
> i am installing a new ULTRA machine with solaris 2.5.1
> and we have users who have a University Number like:
> 9021029 and similars...
> 2 digits = year they entered this Univ.
> 2 digits = carreer number
> 3 digits = order in which they entered this carreer..
> well the thing is that I created account using this number
> as their UID so I do not have to administer
> conflicting UID..and so on..
> but when I add these users to quota, the quota file
> lists like 313 MEGABYTES in an "ls -l" but does not
> actually use that space since an "df -bk" doesn't
> reflect that... CRAZY...
> when i really go bezerk is when i do a "quotacheck -v -a"
> and it eats all the CPU and never comes back..
> The procedure to enable quotas is ok, since in
> other machines it works, but with UID like 10000 and
> below...
> I checked the man pages and found:
> man edquota...
> Users with a UID greater than 67108864 cannot be given quo-
> tas.
> SunOS 5.5.1 Last change: 20 Nov 1995 2
> which i beleive is not the REAL LIMIT!!!
> I have all the patches installed till 1st August 1997.
> Am I missing something?
> has anyone had the same experience??
> can anybody try on their systems to see if they get the same results?


the problem is that SOLARIS can handle very large UID, but
programs like "quota", "elm", Solstice have LOWER limits..

This was resolved by moving everybody to UID 1000 and up..

The reason why the quota file is 313Mbytes is that the quota
program does not support that BIG uid and it HAS to create the
"structure" of data for all the UIDs in between ( 1000 to 9 M)
of blacks...causing 313Mb of nothing..

So,...don't create accounts with UID>60.000

Thanks to all the people who responded..

I attach a complete listing of UID problems gived by
Matthew Stier <>. Thanks.

Known problem. Reference Infodoc 14617


SYNOPSIS: Maximum Number of UID's/GID's that is recommended for 2.X


The maximum number of UID's/GID's that is supported in Solaris 2.3 to
2.5 is a value of 60,000. Listed below is the interoperability matrix
that references the problems encountered with using a value higher
than 60,000.

1) 60003 or greater
                        Is unsupported in the Solstice Adminsuite 2.1
                        software but supported in Solstice Adminsuite
                        2.2 software.

                        Users in this category logging into systems
                        running previous Solaris releases and the NIS
                        or files name service will get a UID and GID of

2) 65535 or greater
                        SunOS 4.x systems running the NFS version 2
                        software will see UID's in this category
                        truncated to 16 bits, creating possible
                        security problems.

                        Users in this category using the cpio command
                        (using the default archive format) to copy
                        files will see and error message for each file
                        and the UID's and GID's will be set to <nobody>
                        in the archive.

                        SPARC systems: Users in this category running
                        SunOS 4.x compatible applications will see
                        EOVERFLOW returns from some system calls, and
                        their UID's and GID's will be mapped to

                        x86 systems: If users in this category attempt
                        to create a file or directory running
                        SVR3-compatible applications will probably see
                        EOVERFLOW return codes from system calls.

                        x86 systems: If users in this category attempt
                        to create a file or directory on a mounted
                        System V file system, the System V file system
                        returns an EOVERFLOW error.

3) 100000 or greater
                        The "ps -l" command displays a maximum
                        five-digit UID so the printed column won't be
                        aligned when they include a UID or GID larger
                        than 99999.

4) 262144 or greater
                        Users in this category using the cpio command
                        (using -H odc format) or the "pax -x" cpio
                        command to copy files will see an error message
                        returned for each file, and the UID's and GID's
                        will be set to <nobody> in the archive.

5) 1000000 or greater
                        Users in this category using the "ar" command
                        will have their UID's and GID's set to <nobody>
                        in the archive.

6) 2097152 or greater

                        Users in this category using the tar command,
                        the "cpio -H" ustar command, or the "pax -x"
                        tar command have their UID's and GID's set to

7) 67108864 or greater

                        The quota database exceeds the two-Gbyte
                        maximum file size in the Solaris 2.5.1 release.
                        Above this limit, users cannot be assigned file
                        system quotas.

8) 100000000 or greater

                        The column alignment of the numeric forms of
                        "ls and "find" output become ragged which may
                        break shell scripts or other commands depending
                        on the column output format.

Marcelo Maraboli Rosselott
Jefe de Area de Redes (Network Administrator)
Direccion Central de Servicios Computacionales (DCSC)
Universidad Tecnica Federico Santa Maria, Chile.

|--| |-[]-| |--| C: uCapacitor The Beginning of the | C I C | I: Electronic New Electronic Age | | Island "Quantum Electronics, That's COOL!" |------()------| V: Voltage "Shut up, Beavis!" V + - ------------------------------------------------------------------/

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:01 CDT