NFS - difference between anon=-2 and anon=65534

[W L Wong]

Hello HP-UX gurus,

Have been trying to find out what exactly is the diff between NFS exporting a filesystem with anon=-2 and anon=65534.

http://docs.hp.com/en/B2355-90131/exports.4.html says anon=65534 is the default value which I suppose is accessible by everyone?

Then, http://docs.hp.com/en/B9106-90011/exports.4.html
says anon=-2 is the default.

So which is which, and what are the differences?

Thanks!

[W L Wong]

One more thing to add - if I export with anon=-2 but remove the root qualifier (root=...) what does that mean?

Do the exported hosts still get r/w access?

Thanks!

[A. Clay Stephenson · Accepted solution]

Surprisingly -2 and 65534 are the same number -- at least they are represented the same as 16-bit values. Negative values are represented as two's-complement. This means that to represent -2, you first represent it +2 in binary:
0000000000000010 == +2
1111111111111101 == one's complement; flip every bit
1111111111111110 == two's complement by adding 1 to the one's complement

1111111111111110 == 65534 as a 16-bit unsigned integer or -2 as a 16-bit signed integer.

This is why these values are interchangable and it also illustrates why every admin should know at least a little assembly language.

[W L Wong]

Thanks for the quick reply and concise reply!

[A. Clay Stephenson]

If you remove the root= entry then root access to the filesystem is not allowed, the anon=-2 means that anonymous rw access to the exported filesystem is allowed. You can restrict the mounts to readonly by adding "ro".

[W L Wong]

Thanks again Clay..you're a champ.

[Jim Keeble]

In HP-UX 10.20, the uid became a 32 bit value instead of 16. In that case, -2 and 65534 (64K-2) are not the same value, instead it is (4G-2) .

If you use -2, the system will interpret it correctly whether the system supports large UID's (32bit, that is) or not.

[A. Clay Stephenson]

While it is true that uid's are 32-bit values on most flavors of UNIX these days, to be backwards compatible the -2 and 65534 equivalence had to be maintained. In fact, it is still an extremely good idea to keep uid's in the 16-bit range so that uid's can remain constant over many flavors of UNIX.