T o n g wrote:
> Bob Proulx wrote:
> > T o n g wrote:
> >> My Autofs auto-mounted NFS share looks like this:
A pet peeve of mine is "share". Windows has "shares". Unix has
"filesystems". NFS is itself a Network File System. So saying
Network File System Share feels like saying a Personal PIN Number. It
would make me happier if people just referred to them as filesystems.
> >> drwxr-xr-x 9 4294967294 4294967294 45056 2011-04-12 09:47 tmp/
Of course that looks like either the 'nobody' user and group or it
looks like a -1 error being propagated. Probably just the nobody user
and group.
> >> I.e., the user id and group id are all mapped wrong.
Because you said the user id and group id are mapped wrong I suggested
to be aware of the --manage-gids option because it changes the
behavior of how users and groups are looked up. For me it is a source
of problem because I don't usually give users accounts on the NFS
server machines. But if --manage-gids is in effect then I would need
to in order to have the server look up their account data. For me
that is "just wrong". However for the bug reporter that I referenced
not having all of the groups were for them "just wrong" too. The
solution is mutually exclusive. One or the other works but not both.
> >> I have identical user ids and groups between my NFS sharing stations,
Just say "workstations that have the same NFS filesystem mounted" or
something to that effect.
> So you are saying to remove it?
No. I am not sure that is your problem. It might be. Not sure. You
didn't include enough information for anyone to know. But since you
have that information and looking at the way the --manage-gids works
should be able to tell if that is your issue or not. It definitely
changes the way account data is looked up.
> I did that and restarted my nfs-kernel-server. Now:
>
> $ ps -ef | grep rpc.mountd
> root 12869 1 0 Jul30 ? 00:00:00 /usr/sbin/rpc.mountd
>
> However, on the client side, Autofs still show the wrong uid and gid.
> Same as in OP.
Then that is not your problem. I think you have improved things
though.
> Anywhere else to check?
Let's back up and start through the debug path.
'ls' is going to stat(2) calls to look up information about those
files. The user and group displayed are mapped through the number
stored in the file's inode metadata. You can see the actual numbers
by using the 'ls -n' option. Or by using 'stat'.
$ ls -ldn yourfoo
drwxr-xr-x 60 1000 1000 4096 Jul 31 18:59 yourfoo
$ stat youfoo
File: `yourfoo'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: fe02h/65026d Inode: 3932162 Links: 60
Access: (0755/drwxr-xr-x) Uid: ( 1000/ rwp) Gid: ( 1000/ rwp)
Access: 2012-07-31 12:44:16.104414486 -0600
Modify: 2012-07-31 18:59:12.254911408 -0600
Change: 2012-07-31 18:59:12.254911408 -0600
See the user and group numbers? The "1000". That is my user id.
After obtaining the number the ls program will look up the matching
name assocatied with that number. In Unix everything is done with the
number. But people like the name to be displayed.
To look up the number from the command line there are a number of
different tools and different ways. GNU glibc provides 'getent'
specifically for this purpose so I will quote it. But with NIS/yp it
would be ypcat or ypmatch. With a traditional Unix system it would
simply be 'grep' of the account from /etc/passwd.
$ getent passwd 1000
rwp:x:1000:1000:Bob Proulx,,,:/home/rwp:/bin/bash
$ getent group 1000
rwp:x:1000:
So that completes path from getting the user and group numbers
assocatied with a file. (And directories are simply files. Just
special files.) And then converting the number to a name.
If the number does not have an associated name in the password or
group databases (/etc/passwd or /etc/group files) then the number
itself is printed.
With the above hints what is going on with your system?
Bob
Attachment:
signature.asc
Description: Digital signature