[
https://issues.apache.org/jira/browse/HDFS-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14255907#comment-14255907
]
Hadoop QA commented on HDFS-7563:
---------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12688665/UID_GID_Long_HashMaps.patch
against trunk revision a696fbb.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:red}-1 javac{color:red}. The patch appears to cause the build to
fail.
Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/9111//console
This message is automatically generated.
> NFS gateway parseStaticMap NumberFormatException
> ------------------------------------------------
>
> Key: HDFS-7563
> URL: https://issues.apache.org/jira/browse/HDFS-7563
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: nfs
> Affects Versions: 2.6.0
> Environment: HDP 2.2
> Reporter: Hari Sekhon
> Assignee: Aaron T. Myers
> Attachments: UID_GID_Long_HashMaps.patch
>
>
> When using the new NFS UID mapping for the HDFS NFS gateway I've discovered
> that my Windows 7 workstation at this bank is passing UID number 4294xxxxxx
> but entering this in the /etc/nfs.map in order to remap that to a Hadoop UID
> prevents the NFS gateway from restarting with the error message:
> {code}Exception in thread "main" java.lang.NumberFormatException: For input
> string: "4294xxxxxx"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:495)
> at java.lang.Integer.parseInt(Integer.java:527)
> at
> org.apache.hadoop.security.ShellBasedIdMapping.parseStaticMap(ShellBasedIdMapping.java:318)
> at
> org.apache.hadoop.security.ShellBasedIdMapping.updateMaps(ShellBasedIdMapping.java:229)
> at
> org.apache.hadoop.security.ShellBasedIdMapping.<init>(ShellBasedIdMapping.java:91)
> at
> org.apache.hadoop.hdfs.nfs.nfs3.RpcProgramNfs3.<init>(RpcProgramNfs3.java:176)
> at org.apache.hadoop.hdfs.nfs.nfs3.Nfs3.<init>(Nfs3.java:45)
> at org.apache.hadoop.hdfs.nfs.nfs3.Nfs3.startService(Nfs3.java:66)
> at org.apache.hadoop.hdfs.nfs.nfs3.Nfs3.main(Nfs3.java:72)
> {code}
> The /etc/nfs.map file simply contains
> {code}
> uid 4294xxxxxx 1yyyy
> {code}
> It seems that the code at
> {code}hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/ShellBasedIdMapping.java{code}
> is expecting an integer at line 318 of the parseStaticMap method: {code}int
> remoteId = Integer.parseInt(lineMatcher.group(2));
> int localId = Integer.parseInt(lineMatcher.group(3));{code}
> This UID does seem very high to me but it has worked successfully on a
> MapR-FS NFS share and stores files created with that UID over NFS.
> The UID / GID mappings for the HDFS NFS gateway will need to be switched to
> using Long to accomodate this, I've attached a patch for the parsing and
> UID/GID HashMaps.
> Regards,
> Hari Sekhon
> http://www.linkedin.com/in/harisekhon
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
