Skip to main content

Overview

copyparty supports multiple authentication methods:
  • Basic authentication - Built-in username/password accounts
  • IP-based authentication - Auto-login based on IP address/range
  • Identity providers (IdP) - OAuth, LDAP, Active Directory, SAML
  • Header-based authentication - Integration with reverse proxy auth
  • User-changeable passwords - Let users manage their own passwords

Basic Authentication

Creating User Accounts

1

Command-line accounts

Create accounts with the -a flag:
Both users can access /files with their respective passwords.
2

Configuration file accounts

For better security and management:
accounts.conf
Start with:
3

Require usernames

By default, users can login with password only. Enable username requirement:
Users must now enter both username AND password.

User Groups

Organize users into groups for easier management:

Password Hashing

Store hashed passwords instead of plaintext:
Use in config:
Or hash all passwords:
  • --ah-alg 6 - Use bcrypt with cost factor 12
  • Passwords are auto-hashed on first use

User-Changeable Passwords

Let users change their own passwords:
  • --chpw - Enable password changing
  • Users access via control-panel
  • New passwords stored in chpw.json by default
Exclude specific accounts from changing passwords:

IP-Based Authentication

Auto-Login by IP Range

Automatically log in users from specific networks:
  • Anyone from 192.168.1.0/24 auto-logs in as alice
  • No password prompt for those IPs
Multiple IP ranges:

Restrict Users to IP Ranges

Limit which IPs can use an account:
  • User remote-worker can ONLY login from 203.0.113.0/24
  • Connections from other IPs are rejected
Configuration example:
Important: If using a reverse proxy, ensure real-ip detection is configured correctly! Otherwise, copyparty sees the proxy IP, not the client IP.

Identity Provider (SSO) Integration

Overview

Replace copyparty’s built-in authentication with external identity providers:
  • Authelia - Config-file based IdP
  • Authentik - GUI-based IdP with advanced features
  • Keycloak - Enterprise SSO solution
  • OAuth providers - Google, GitHub, etc.
  • LDAP / Active Directory
  • SAML providers

How It Works

  1. User visits copyparty
  2. Reverse proxy redirects to IdP login
  3. User authenticates with IdP
  4. IdP sends username via HTTP header
  5. copyparty reads header and grants access

Basic IdP Setup

Configure copyparty to trust a header:
Start with:

Authelia Integration

Complete example with Authelia IdP:
1

Install Authelia

2

Configure Authelia

In authelia-config.yml:
3

Configure copyparty

copyparty.conf
4

Configure reverse proxy

Nginx example:

Generic Header Authentication

Map any header to copyparty users:
Format: ^HeaderName^HeaderValue^CopypartyUsername

Authentication Precedence

Control which auth method takes priority:
Use cases:
  • idp,pwd - Normal operation, with password fallback
  • pwd,idp - Let admin override IdP with password

WebDAV Authentication

WebDAV clients often struggle with IdP authentication.

Password-Based WebDAV

Force password auth for WebDAV:
Users access WebDAV with alice:webdav-password, but web UI uses IdP.

Separate WebDAV Port

Run WebDAV on a different port without IdP:
Configure reverse proxy to:
  • Port 3923: Web UI with IdP auth
  • Port 3980: WebDAV with password auth (no IdP)

Session Management

Session Cookies

Reduce IdP load with session cookies:
After first login:
  • copyparty sets a cppws cookie
  • Future requests skip IdP validation
  • Cookie expires after 24 hours (default)

Session Timeout

Advanced Authentication Patterns

Public Read, Authenticated Write

Multiple Auth Levels

Temporary Access

Use the shares feature for temporary authenticated access:
Admin creates shares with:
  • Custom expiration time
  • Optional password
  • Access to specific files/folders
Shares bypass normal authentication.

Ban and Rate Limiting

Failed Login Protection

  • 5 failed attempts
  • In 3600 seconds (1 hour)
  • Results in 86400 second ban (24 hours)
Configuration:

Whitelist IPs from Bans

Complete SSO Example

complete-sso.conf

Troubleshooting

This means they’re banned for suspicious activity.Solutions:
  1. Check ban settings: --ban-pw, --ban-404
  2. Configure real-IP detection: --xff-hdr, --xff-src
  3. Whitelist trusted IPs
  4. Check server logs for ban reason
Temporary fix:
Check these:
  1. Header name matches: idp-h-usr: Remote-User
  2. Reverse proxy sends header: check nginx/apache config
  3. Real-IP configured: --xff-hdr, --rproxy
  4. Account exists in copyparty config
  5. Check server logs for header values
Debug:
WebDAV often incompatible with IdP.Solutions:
  1. Enable password auth: dav-auth
  2. Use separate port: dav-port: 3980
  3. Set account password: alice: webdav-pass
  4. Check user-agent: some need og_ua configured
Check:
  1. --chpw enabled
  2. Write permission on chpw-db file (default chpw.json)
  3. Account not in chpw-no list
  4. Not using IdP (incompatible with --chpw)
Reverse proxy issues:
  1. Configure real-IP: --xff-hdr x-forwarded-for
  2. Trust proxy: --xff-src 172.16.0.0/12
  3. Set rproxy mode: --rproxy -1
  4. Check server logs for detected IP
Test without proxy first to verify config.

Security Best Practices

Use HTTPS

Always use HTTPS in production:
Or use a reverse proxy with TLS.

Hash Passwords

Never store plaintext passwords:

Rate Limiting

Enable ban protection:

Least Privilege

Grant minimum required permissions:

Monitor Access

Enable logging and monitoring:

Next Steps