Skip to content

[Feature Request] Volume-level IP/network restrictions (volflag or accs syntax) #1132

@BenMcLean

Description

@BenMcLean

Is your feature request related to a problem? Please describe.

Currently, copyparty supports restricting user accounts to specific IP ranges using the global --ipr option:

[global]
  ipr: 192.168.0.0/24,127.0.0.1/32=lanuser

However, this is an account-level restriction. It would be very useful to have volume-level IP restrictions, where access to a specific volume is blocked based on the client's IP address, regardless of which account they're using.

Describe the solution you'd like

I want to expose a config/admin volume that should only be accessible from my local network, while other volumes remain accessible from the internet. With account-level restrictions, if I want to give a user access to both volumes, I'd need to create separate user accounts or use workarounds.

Desired syntax option 1 (using accs-style syntax):

[/_Config]
  /cfg
  accs:
    rwmda: lanuser
  allow-ip: 127.0.0.1/32,192.168.0.0/24

Desired syntax option 2 (as a volflag):

[/_Config]
  /cfg
  accs:
    rwmda: lanuser
  flags:
    ip-allow: 127.0.0.1/32,192.168.0.0/24

Describe alternatives you've considered

  • Using --ipr at the account level: This requires creating multiple accounts per user if they need different access patterns across volumes (e.g., lanuser for LAN-only volumes and nasuser-internet for public volumes). This creates a maintenance burden.
  • Reverse proxy with location-based IP filtering: Adds complexity and an additional layer to maintain.
  • Firewall rules: Less granular, affects entire server rather than specific volumes.

Additional context

This would allow administrators to create security boundaries at the volume level based on network origin, which is particularly useful for:

  • Admin/config volumes that should never be exposed to the internet
  • Sensitive data that should only be accessible from trusted networks
  • Multi-tier access architectures where some content is public and some is LAN-only

The current --ipr works well but operates at the wrong level of granularity for this use case.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions