e07@nikhefh.nikhef.nl (Eric Wassenaar) (12/18/89)
If an SR10 apollo filesystem has been mounted via nfs by a remote (non-apollo) host, arbitrary remote users on that remote host cannot access any file on the apollo disk via nfs. Only remote users that have an identical account on the SR10 system are allowed access. This means that if a remote user UUU belonging to remote group GGG wants to use nfs with the apollo disks, there must be not only an SR10 person UUU and an SR10 group GGG with identical numeric unix uid and gid, but there MUST also be an SR10 account UUU.GGG.org for nfs to work. This is absolutely unacceptable. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl
e07@nikhefh.nikhef.nl (Eric Wassenaar) (12/18/89)
This is a continuation of my previous posting, which reported that you must have a real account on SR10 before you can access an SR10 apollo disk via nfs from a remote (non-apollo) host. As a consequence, every remote program that does a stat() of statfs() for an apollo nfs disk, will fail with authorization errors. Needless to say this is terribly annoying is you realize that often used utilities on normal bsd4.3 machines like '/bin/df' also deal with nfs mounted filesystems. Every time one of my innocent remote users does a 'df', an authorization error is reported on the remote machine, and many, many lines are added to the SR10 /usr/adm/nfs_error_log file. nfsd: _svcauth_aegis(): FYI unable to convert uid N, gid M, to a SID _svc_auth_aegis(): unable to cache new user uid N, gid M Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl