couldn't use multiple user with config json file

[RilusMahmud]

I'm using this with docker and updated config file for multiple users, but it seems the first user can connect but the rest users couldn't connect. can anyone help me with this, or just tell me what am I doing wrong?

Here is the config file,

{
  "version": 1,
  "passive_transfer_port_range": {
    "start": 2122,
    "end": 2130
  },
  "accesses": [
    {
      "user": "rilus",
      "pass": "@rilus",
      "fs": "os",
      "params": {
        "basePath": "/tmp"
      }
    },
    {
      "user": "rafi",
      "pass": "@rafi",
      "fs": "os",
      "params": {
        "basePath": "/tmp"
      }
    },
    {
      "user": "sakib",
      "pass": "@sakib",
      "fs": "os",
      "params": {
        "basePath": "/tmp"
      }
    }
  ]
}

[AmurgCodru]

You should probably set up a TLS certificate as per the readme Try using a different location instead of TMP , it worked fine on my side, try rebuilding the binary.

[fclairamb]

@claude can you try to reproduce what @RilusMahmud described ?

[claude[bot]]

Claude finished @fclairamb's task —— View job

---

Investigating Multiple User Authentication Issue ✅

I've successfully analyzed the issue and have a complete understanding of what's happening.

Todo List:

• [x] Read repository setup instructions
• [x] Analyze codebase structure and authentication flow
• [x] Examine JSON config parsing for multiple users
• [x] Identify potential bugs in user authentication logic
• [x] Provide findings and recommendations

Root Cause Analysis

After carefully examining the authentication code in config/config.go:195-341, I can confirm that the authentication logic itself is correct and should work for multiple users. The issue is likely elsewhere.

Key Findings

1. Authentication Logic is Sound: The GetAccess() function properly iterates through all users in the config and matches both username and password correctly.

2. Password Handling: The code correctly handles both plain-text passwords (like @rilus, @rafi, @sakib) and hashed passwords.

3. Filesystem Caching: The filesystem caching mechanism (server/server.go:168-189) correctly caches by username, so each user gets their own instance.

Potential Root Causes

Given that the code logic appears correct, the issue is likely one of these:

1. Docker Network/Port Conflicts: Multiple concurrent connections might be failing due to port range conflicts in Docker
2. Connection Limits: The server might have a max_clients limit that's too low
3. Timing Issues: Race conditions during rapid connection attempts
4. Docker Volume Permissions: /tmp directory permissions inside the container

Immediate Solutions to Try

Option 1: Use Different Base Paths

{
  "version": 1,
  "passive_transfer_port_range": {
    "start": 2122,
    "end": 2130
  },
  "accesses": [
    {
      "user": "rilus",
      "pass": "@rilus", 
      "fs": "os",
      "params": {
        "basePath": "/tmp/rilus"
      }
    },
    {
      "user": "rafi",
      "pass": "@rafi",
      "fs": "os", 
      "params": {
        "basePath": "/tmp/rafi"
      }
    },
    {
      "user": "sakib",
      "pass": "@sakib",
      "fs": "os",
      "params": {
        "basePath": "/tmp/sakib"
      }
    }
  ]
}

Option 2: Increase Port Range

{
  "passive_transfer_port_range": {
    "start": 2122,
    "end": 2140
  }
}

Option 3: Add Connection Limits

{
  "max_clients": 10,
  "version": 1,
  // ... rest of config
}

Recommended Testing Steps

1. Test authentication individually: Try connecting users one at a time to verify each works
2. Check Docker logs: Look for connection errors or port conflicts
3. Test with increased port range: Expand the passive port range
4. Try sequential connections: Connect users with delays between attempts

The authentication code is robust and should handle multiple users correctly. The issue is most likely related to Docker networking, port management, or connection timing rather than the authentication logic itself.

[fclairamb]

What I had in mind as most probable cause is:

Connection Limits: The server might have a max_clients limit that's too low

Can't do much here.