Moving and sharing
Sharing One Library With Other People
A shared music server has an unusual requirement: the library is common but the taste is not. Aurral keeps history, feedback, blocklists and the Inbox per user so two people sharing one server do not end up sharing one set of recommendations.
What is per user and what is shared
This distinction is the whole design. If it were not per user, adding a second listener would silently corrupt the first listener's recommendations.
| Per user | Shared |
|---|---|
| Listening history and scrobbling | The music library itself |
| Recommendation feedback and blocklist | Download jobs and settings |
| Inbox read, saved and dismissed state | Quality profile and source priority |
| Favourites | Integration credentials |
| Discover page layout and order | Monitored state on artists and albums |
| Listening-history provider | Weekly schedules for shared Flows |
Permissions
Settings has a Users tab covering accounts, permissions, account status and sign-in mode. An admin decides what a non-admin account can do.
The sensible default is that a regular user can browse, play, give feedback, manage their own favourites and start searches, but cannot change server configuration or integration credentials. Manual searches in particular are worth keeping available, because they only affect the user who starts them.
- Admin: configuration, integrations, user management.
- Regular: browse, play, feedback, favourites, own searches.
- Account status: active or disabled, without deleting history.
Sign-in modes
Aurral supports local accounts, reverse-proxy SSO and native OIDC. Local network auto-login is a separate convenience for trusted networks.
Local auto-login is genuinely convenient on a home LAN and genuinely wrong if the server is reachable from outside. Decide based on your network rather than on convenience.
| Mode | Good for | Watch out for |
|---|---|---|
| Local accounts | Full control, works offline | Password management is yours |
| Reverse-proxy SSO | Already behind an authenticating proxy | Header forwarding must be exact |
| Native OIDC | You have an identity provider | More setup than the other two |
| LAN auto-login | Trusted home network | Do not enable on an exposed server |
Per-listener recommendations
Each user's seeds come from their own likes, their own listening history and their own library sample. Two people with identical libraries still get different recommendations once their history differs.
Selecting your own listening-history provider is per user too, so one person can use Last.fm while another keeps everything local. Changing provider rebuilds that user's recommendations only.
Sharing sources without sharing playlists
Library source in a Flow means every user's Flow draws on the shared collection, which is usually the point. If one person wants a Flow that ignores what they own, turn the Library source off for that Flow.
Playlist publishing names differ per server for exactly this reason. Navidrome prefixes with the username by default so two people can both have a playlist called Late Night Drive.
Frequently asked questions
Do family members need their own accounts?
For separate recommendations, yes. Sharing one account means sharing history, and therefore sharing one set of picks.
Can I disable an account without losing its history?
Yes. Account status handles that, as distinct from deleting the account.
Is LAN auto-login safe on a home network?
On a genuinely trusted LAN, yes. Not if the server is reachable from outside, which is the case people most often forget about.
Can two people both have a playlist called the same thing?
Yes. Flow and static playlist names are unique per installation rather than per user, so pick distinct names, and Navidrome additionally prefixes with the username.
Ready to set it up
One container and one media path is genuinely all it takes. Everything else in this page is something you add when the need appears.