Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux Install: Recommend not mounting <library_path> directly #135

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Zuuushiiihokkiii
Copy link

Protect users from data loss if the storage backing <library_path> is unmounted and Navidrome scans the library by recommending to store <library_path> in a subdirectory of the mount point instead of mounting it directly.

Navidrome deletes all songs from the database if <library_path> exists but is an empty mount point, permanently deleting playlist contents, favourites and play counts. If <library_path> does not exist, the scan simply fails and the database is not modified.

Protect users from data loss if <library_path> unmounted and Navidrome scans the library by recommending to store <library_path> in a subdirectory of the mount point. Navidrome deletes all songs from the database if <library_path> exists but is an empty mount point, permanently deleting playlist contents, favourites and play counts. If <library_path> does not exist, the scan simply fails and the database is not modified.
@deluan
Copy link
Member

deluan commented Oct 26, 2023

This was already fixed in Navidrome in newer versions and should not be an issue anymore: navidrome/navidrome#893

Are you still experiencing this?

@Zuuushiiihokkiii
Copy link
Author

@deluan Hi, thanks for responding. Yes, I had some time today so I set up a test container with the latest release 51.0 to get to the bottom of this, and can confirm that this is still happening, but it's not a bug:

Why this happens

I had a look at the changes in the issue you linked: navidrome/navidrome#893

At line 83 in tag_scanner.go I found the check to abort the scan is actually if empty && !fullScan.

This makes a lot of sense. If I remove all the content from my library and click "full scan", I would expect Navidrome to remove all the songs, and not abort the scan.

How this can quickly lead to data loss

Knowing this, this is how I lost my database:

  1. Navidrome was running, with the library mounted
  2. The connection to the storage server was lost at some point, the library was unmounted and not automatically re-mounted
  3. I uploaded some new music to the storage server
  4. I logged into Navidrome, expecting to see my new content, but it was not there... so I clicked "full scan", and since the library was not mounted, Navidrome saw an empty directory, but this was a full scan, so it did exactly what it was supposed to and deleted all songs from the database.

I had a good backup and it was no big deal, but it could be for others.

My suggestion to prevent this happening accidentally

In navidrome.service I bind the service to the mount unit with After and BindsTo. Should the library get unmounted for any reason, Navidrome will be stopped and systemd will refuse to start it until the library is successfully mounted again.

[Unit]
# Bind to mount unit, so Navidrome will never be active if the library is unmounted
After=mnt-navidrome\x2dlibrary.mount
BindsTo=mnt-navidrome\x2dlibrary.mount

This provides full protection from accidentally starting a full scan on an unmounted library.

I see no point in allowing Navidrome to start when the library is unavailable, so as far as I can tell there is no downside. Maybe something like this could be added in the installation instructions as a commented out section in the systemd unit?

@deluan
Copy link
Member

deluan commented Feb 16, 2024

I think it makes sense. Can you please open a PR to change the script? Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants