0

Been grappling with this for a few days and need some help, GOOGLE'in around hasnt yielded anything that worked as of yet. So here is the situation (apologies if I miss anything):

-There is a main system that works fine with many mounted HDs

-There are several side systems with their own processors that also mount the same HDs. The side systems (nodes?) shares home directories with the main system

-I have sudo access to all systems so I can check whatever

-I have created users on both systems with same UIDs and groupIDs and affiliated groups (confirmed using id USERNAME and checking /etc/passwd and /etc/group on both systems [pasted below])

  • Whenever I create something on the main system, all looks good

  • Whenever I create something on the side system, group seems to work right, but user does not.

-2 other users of the systems have none of my problems (worked fine for the last 3 years for them). I just joined the team and we cant get it to work right for me.

-Im told its nfs mounted though i'm less familiar with these things than one might prefer so I have no other details

-Below some stats:

USERNAME katz

UID 1019

sidesystem: UBUNTU 14.04 mainsystem: UBUNTU 12.02

katz@SIDESYSTEM:/home/katz$ cat /etc/passwd | grep katz
katz:x:1019:1019::/home/katz/:/bin/bash

katz@MAINSYSTEM:~$ cat /etc/passwd | grep katz
katz:x:1019:1019:My Name,,,:/home/katz/:/bin/bash

then

katz@SIDESYSTEM:/home/katz$ ls -1l | grep bk
-rw-rw-r-- 1 nobody katz          0 Jul 20 22:06 bk

katz@MAINSYSTEM:~$ pwd
/home/katz/
katz@MAINSYSTEM:~$ ls -1l | grep bk
-rw-rw-r-- 1 katz katz          0 Jul 20 22:06 bk

In reading other potential answers on this site, below are a few other potentially useful bits:

katz@SIDESYSTEM:/home/katz$ cat /etc/exports   [Some numbers replaced with Xs for privacy]
# /etc/exports: the access control list for filesystems which may be exported
#       to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#
/dataXX          XX.XX.X.XX(rw,async,no_root_squash,no_subtree_check)
/dataXX          XX.XX.X.XX(rw,async,no_root_squash,no_subtree_check)
....etc.

katz@MAINSYSTEM:~$ cat /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
#       to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#
/home           XX.XX.X.XX(rw,async,no_root_squash,no_subtree_check)
...etc

Happy to add any other information others think would be helpful.

0

You specified your share with NFSv3-style syntax. When mounting on the client, try mounting with -o nfsvers=3

mount -t nfs 1.2.3.4:/home /home -o nfsvers=3

By default, NFSv4 is used which is kind of compatible with v3, so the mount succeeds, but the mapping of user ids and permissions is messed up. So either use NFSv4 server-side or force the client to use v3 using that option.

2
  • I will certainly try this when possible, but we have a bunch of jobs running on the machine that we can't kill for a week or two or three, otherwise we risk loosing a bunch of work. Are there any temporary solutions that could allay this problem? Very much appreciate your answer and your time. – bgk111 Jul 22 '16 at 6:23
  • None that I know of, while you're using the mountpoint. You can try mounting another share for testing purposes, maybe create one to see if it works. – jr98 Jul 22 '16 at 6:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.