What causes "get current user: %s" in juicedata/juicefs?

Set HADOOP_USER_NAME to a valid HDFS user so user.Current() is never called.

get current user: %s

Error message

get current user: %s

What it means

For non-Kerberos clusters newHDFS derives the HDFS user: an explicit username argument, then HADOOP_USER_NAME, then the OS current user via user.Current(). If user.Current() fails (OS account lookup error), the client creation aborts with "get current user: %s". This happens only when no username was supplied and HADOOP_USER_NAME is empty.

Source

Thrown at pkg/object/hdfs.go:325

	options := hdfs.ClientOptionsFromConf(conf)
	if addr != "" {
		options.Addresses = rpcAddr
		logger.Infof("HDFS Addresses: %s, basePath: %s", rpcAddr, basePath)
	}

	if options.KerberosClient != nil {
		options.KerberosClient, err = getKerberosClient()
		if err != nil {
			return nil, fmt.Errorf("Problem with kerberos authentication: %s", err)
		}
	} else {
		if username == "" {
			username = os.Getenv("HADOOP_USER_NAME")
		}
		if username == "" {
			current, err := user.Current()
			if err != nil {
				return nil, fmt.Errorf("get current user: %s", err)
			}
			username = current.Username
		}
		options.User = username
	}

	c, err := hdfs.NewClient(options)
	if err != nil {
		return nil, fmt.Errorf("new HDFS client %s: %s", rpcAddr, err)
	}
	if os.Getenv("HADOOP_SUPER_USER") != "" {
		superuser = os.Getenv("HADOOP_SUPER_USER")
	}
	if os.Getenv("HADOOP_SUPER_GROUP") != "" {
		supergroup = os.Getenv("HADOOP_SUPER_GROUP")
	}

	var replication = 3

View on GitHub (pinned to c9a67b23e8)

Solutions

Set HADOOP_USER_NAME to a valid HDFS user so user.Current() is never called.
Pass the username explicitly where the object storage is registered (the username argument of newHDFS).
Ensure a /etc/passwd entry exists for the process uid (adduser/echo to passwd in the container).
If using the static binary, prefer setting HADOOP_USER_NAME over relying on cgo-based user lookup.

Example fix

// before
$ ./juicefs -static mount hdfs://nn:9000/data /mnt/jfs   # uid 10001, no passwd entry
get current user: user: unknown userid 10001
// after
$ export HADOOP_USER_NAME=hdfs
$ ./juicefs -static mount hdfs://nn:9000/data /mnt/jfs

Defensive patterns

Strategy: validation

Validate before calling

if os.Getenv("HADOOP_USER_NAME") == "" {
    if _, err := user.Current(); err != nil {
        return fmt.Errorf("set HADOOP_USER_NAME: cannot resolve current user: %w", err)
    }
}

Try / catch

os, err := object.CreateStorage("hdfs", addr, "", "")
if err != nil && strings.Contains(err.Error(), "get current user") {
    logger.Fatalf("HDFS user lookup failed: %v — set HADOOP_USER_NAME explicitly", err)
}

Prevention

Always set HADOOP_USER_NAME in containers or when using static binaries.
Give the process uid a /etc/passwd entry (adduser) in minimal images.
Pass the username explicitly when registering HDFS storage instead of relying on OS lookup.
Test user resolution in your container before production rollout.

When it happens

Trigger: newHDFS invoked without a username and without HADOOP_USER_NAME set, on a system where user.Current() fails — e.g. statically linked binary without cgo unable to resolve the uid to a passwd entry, or the process running under a uid with no /etc/passwd entry (common in minimal containers).

Common situations: Running the static (musl) JuiceFS binary in a scratch/alpine container whose user has no passwd entry; running as an arbitrary --user uid in Docker; nsswitch misconfiguration.

Understand the failure class

Background: "User not found", "Invalid user", and "does not exist": what missing-user lookup errors mean across Rocket.Chat, LiteLLM, Phabricator, rustfs, and pnpm — this error's family across 10 libraries.

Related errors

AI-assisted analysis of juicedata/juicefs@c9a67b23e8 (2026-09-06). Data as JSON: /api/errors/5c7072a25c7e639f. Report an issue: GitHub.