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
signature.asc
Description: Digital signature