Open jbeal-work opened 1 year ago
korydraughn
commented
1 year ago I see an invalid client user error.
Q. Are you trying to access a federated zone via NFSRODS? Q. What rodsadmin user is NFSRODS configured to use? Q. What Unix username are you attempting to access the mount point as? Q. Is /etc/hosts being used to resolve Unix usernames to iRODS usernames?
jbeal-work
commented
1 year ago Q. Are you trying to access a federated zone via NFSRODS?
I think so the machine is part of the humgen zone and I am accessing something in the SANGER zone
Q. What rodsadmin user is NFSRODS configured to use?
"irods_client": {
"zone": "humgen",
"host": "irods-hum-nfsrods01.internal.sanger.ac.uk",
"port": 1247,
"default_resource": "demoResc",
"ssl_negotiation_policy": "CS_NEG_REQUIRE",
"connection_timeout_in_seconds": 600,
"proxy_admin_account": {
"username": "nfsrods",
"password": "*****"
}
}Q. What Unix username are you attempting to access the mount point as?
jb23
Q. Is /etc/hosts being used to resolve Unix usernames to iRODS usernames?
I am not sure I understand the question /etc/hosts and Unix usernames -> iRODS usernames ?
We are using DNS for hostname lookup, our users are in LDAP via sssd
korydraughn
commented
1 year ago Q. Is /etc/hosts being used to resolve Unix usernames to iRODS usernames?
I am not sure I understand the question /etc/hosts and Unix usernames -> iRODS usernames ?
We are using DNS for hostname lookup, our users are in LDAP via sssd
Sorry, I meant /etc/passwd instead of /etc/hosts. You provided what I wanted to know though :-).
I'm wondering if the problem has to do with the username seen by NFSRODS and iRODS. We'll look into reproducing this issue.
What OS and version of iRODS are you running?
jbeal-work
commented
1 year ago Sorry stupid architecture question, the docker container with nfsrods is a iRODS client talking to a local server ?
jb23@irods-hum-nfsrods01:/$ cat /etc/issue
Ubuntu 18.04.4 LTS \n \l
jb23@irods-hum-nfsrods01:/$ apt-cache policy irods-server
irods-server:
Installed: 4.2.7
Candidate: 4.2.11-1~xenial
Version table:
4.2.11-1~xenial 500
500 https://packages.irods.org/apt xenial/main amd64 Packages
4.2.10 500
500 https://packages.irods.org/apt xenial/main amd64 Packages
4.2.9 500
500 https://packages.irods.org/apt xenial/main amd64 Packages
4.2.8 500
500 https://packages.irods.org/apt xenial/main amd64 Packages
*** 4.2.7 500
500 https://packages.irods.org/apt xenial/main amd64 Packages
100 /var/lib/dpkg/statusYes. It translates NFS operations into iRODS API calls.
jbeal-work
commented
1 year ago Any thoughts ?
korydraughn
commented
1 year ago Nothing yet. We'll update the issue once we know more.
What version of NFSRODS are you using?
jbeal-work
commented
1 year ago We are using 2.1.0
korydraughn
commented
1 year ago Please confirm the following. I want to make sure I've captured the correct info.
I just noticed the default resource in your NFSRODS config is set to demoResc. Is that correct? Is this a testing environment?
And can you explain these lines from your first post?
jb23@farm5-humgen-nfsrods:~$ cd /mnt/humgen/home/j
****** jc18#Sanger1/ *****
jb23#Sanger1/ *****The default resource is set to demoResc, neither the hugen or the Sanger1 zone are testing enviroments.
I just deleted the output that may have been private.
kript
commented
1 year ago
- You're trying to access the Sanger1 zone through NFSRODS/humgen as jb23
No, he is accessing /humgen/home/jb23#Sanger1 i.e. a local to the zone homedir, with a local to the zone account, however, due to the way (AIUI) NFSRODS does its mappings, it wont resolve jb23#Sanger but instead will lookup system uid jb23 to jb23#humgen user.
So the jb23 NFSRODS tries to access /humgen/home/jb23#Sanger1 with is actually jb23#humgen - there is no way to have it in fact be jb23#Sanger. However, for historical reasons, a lot of users dont have humgen zone accounts - like James it seems!
kript
commented
1 year ago In case its not clear, the only account in that zone for jb23 was jb23#Sanger1
korydraughn
commented
1 year ago Based on what has been said, the behavior you're seeing is expected. NFSRODS is implemented to present a single collection within a zone. It assumes that every user accessing the mount point is a member of the zone it is configured to handle. This explains why you received an invalid client user exception in the log file.
Notice line 40 below. NFSRODS instantiates all iRODS users using the zone defined in the config file. https://github.com/irods/irods_client_nfsrods/blob/6f316fc9b3b75440b8a2e5bad515a13dcc2b9f7e/irods-vfs-impl/src/main/java/org/irods/nfsrods/vfs/IRODSUser.java#L22-L44
Is the behavior you're seeing surprising? What do you feel NFSRODS should do in this case?
trel
commented
9 months ago I don't think NFSRODS can do anything about this scenario.
Ideas welcome.
On the client some access does work for example ls /home works
The nfs server config is