path cache mkdir cache: permission denied[Bug]:

conartist6 commented 6 months ago

I confirm that:

[X] I have searched the existing open AND closed issues to see if an issue already exists for the bug I've encountered
[X] I'm using the latest version (your issue may have been fixed already)

Version

0.50.2 (823bef54)

Current Behavior

I can start navidrome by running the executable, but when I attempt to start navidrome with systemd it reports

FATAL: Error creating cache path: path cache mkdir cache: permission denied

Expected Behavior

I would at least like for the log message to tell me which path it has been denied permission to access so that I could troubleshoot the problem

Steps To Reproduce

...???

Environment

Raspbian GNU/Linux 11 (bullseye)

How Navidrome is installed?

Binary (from downloads page)

Configuration

No response

Relevant log output

No response

Anything else?

No response

Code of Conduct

[X] I agree to follow Navidrome's Code of Conduct

codenamek83 commented 6 months ago

What a coincidence! I was looking to move the cache directory to a different location and ran into the same issue.

metalheim commented 6 months ago

The cache directory is in your data folder. Where the the data folder is depends on your Installation method and on your configuration. Navidrome has to have full read/write permissions to the data folder (to be able to write to the database and create cachr files)

miversen33 commented 6 months ago

I'm running into the same issue. I am using a modified version of the docker compose configuration

version: "3.7"
services:
    navidrome:
      image: deluan/navidrome:latest
      container_name: navidrome
      hostname: navidrome
      user: 1000:1000
      ports:
        - 4533:4533
      restart: unless-stopped
      environment:
        ND_SCANSCHEDULE: 1h
        ND_LOGLEVEL: info
        ND_SESSIONTIMEOUT: 24h
      volumes:
        - navidrome_data:/data
        - /mnt/Media_Store/Music:/music
volumes:
  navidrome_data:

I would expect this to work as docker is simply creating an empty volume and giving it to the container. I suspect the issue is that I am declaring a user (as specified by the config).

Edit: Removing the user tag from the config got this up and running. So it is indeed an issue that the user (whatever uid used) does not have write access to a volume given by docker compose. I could likely fix this via some modifications to the volume in the docker compose yaml but honestly, just removing the tag is easier

codenamek83 commented 6 months ago

The cache directory is in your data folder. Where the the data folder is depends on your Installation method and on your configuration. Navidrome has to have full read/write permissions to the data folder (to be able to write to the database and create cachr files)

Is it possible to move the Cache directory to a different path outside the Data directory?

conartist6 commented 6 months ago

I'd appreciate that too as I'm running this on a raspberry PI, and I like to keep cache stuff on a proper tmpfs so that my SD card can live a long and healthy life

deluan commented 6 months ago

Is it possible to move the Cache directory to a different path outside the Data directory?

Yes it is. Look for CacheFolder in the documentation.

codenamek83 commented 6 months ago

Is it possible to move the Cache directory to a different path outside the Data directory?

Yes it is. Look for CacheFolder in the documentation.

Thank you for the response. I've mounted three volumes (bind-mount) to the container, and I'm encountering a 'path cache mkdir cache: permission denied' issue. The user has full read and write access to the mount from the container. I removed the ND_CACHEFOLDER variable and tried this manually to ensure that it's not a permission problem.

Config:

`volumes:

/path/to/navidrome01:/data
/path/to/navidrome01-cache:/cache
/path/to/music:/music:ro environment:
ND_CACHEFOLDER="./cache"`

PS: I also tried ND_CACHEFOLDER="cache". ND_CACHEFOLDER="/cache"`.

deluan commented 6 months ago

In your case, path must be /cache (same as the volume)

Can you post your full docker-compose.yml? What is your host OS? If it is Linux can you check permissions of the folder by doing a ls -ld /path/to/navidrome01-cache and post here, please?

codenamek83 commented 5 months ago

In your case, path must be /cache (same as the volume)

Can you post your full docker-compose.yml? What is your host OS? If it is Linux can you check permissions of the folder by doing a ls -ld /path/to/navidrome01-cache and post here, please?

`version: "3.8"

services: navidrome01: user: 1000:1000 image: deluan/navidrome:0.50.2 container_name: navidrome01 hostname: navidrome01 networks:

navidrome01 ports:
8106:4533 volumes:
/data/homefs/bindmount/navidrome01:/data
/data/homefs/bindmount-cache/navidrome01:/cache
/data/homefs/entertainment/music:/music:ro environment:
TZ=Asia/Singapore
ND_LOGLEVEL=info
ND_DEFAULTTHEME=spotify-ish
ND_IMAGECACHESIZE=5GB
ND_TRANSCODINGCACHESIZE=5GB
ND_CACHEFOLDER="/cache"
ND_ENABLEDOWNLOADS=false
ND_ENABLEUSEREDITING=true
ND_SCANSCHEDULE=1h
ND_SESSIONTIMEOUT=24h
ND_PLAYLISTSPATH=playlists
ND_COVERARTPRIORITY=cover.*
ND_PASSWORDENCRYPTIONKEY=
ND_LASTFM_ENABLED=true
ND_LASTFM_LANGUAGE=en
ND_LASTFM_APIKEY=
ND_LASTFM_SECRET=
ND_SPOTIFY_ID=
ND_SPOTIFY_SECRET=
ND_UIWELCOMEMESSAGE="Own your music, do not rent it!" restart: unless-stopped security_opt:
no-new-privileges:true

networks: navidrome01: name: navidrome01 driver: bridge`

What is your host OS? Debian GNU/Linux 11 (bullseye) aarch64 (Raspberry)

f it is Linux can you check permissions of the folder by doing a ls -ld /path/to/navidrome01-cache and post here, please? drwxr-xr-x 2 adm-tom adm-tom 4096 Jan 4 02:34 bindmount-cache/

sastromo commented 5 months ago

Im also having this problem after I start the container. Any possible solutions?? Im kinda lost :)

Screenshot_3

goppinath commented 5 months ago

I'm running into the same issue. I am using a modified version of the docker compose configuration
version: "3.7"
services:
    navidrome:
      image: deluan/navidrome:latest
      container_name: navidrome
      hostname: navidrome
      user: 1000:1000
      ports:
        - 4533:4533
      restart: unless-stopped
      environment:
        ND_SCANSCHEDULE: 1h
        ND_LOGLEVEL: info
        ND_SESSIONTIMEOUT: 24h
      volumes:
        - navidrome_data:/data
        - /mnt/Media_Store/Music:/music
volumes:
  navidrome_data:
I would expect this to work as docker is simply creating an empty volume and giving it to the container. I suspect the issue is that I am declaring a user (as specified by the config).

Edit: Removing the user tag from the config got this up and running. So it is indeed an issue that the user (whatever uid used) does not have write access to a volume given by docker compose. I could likely fix this via some modifications to the volume in the docker compose yaml but honestly, just removing the tag is easier

Yes, removing the user: 1000:1000 property resolved the issue.

lukebouch commented 4 months ago

Yes, removing the user: 1000:1000 property resolved the issue.

Why does that fix it?

Fusion86 commented 3 months ago

Why does that fix it?

I believe that runs the container with root permissions on the mounted directories.

What seemed to fix the issue for me is to manually create the ./data/cache folder with the correct permissions. After that the docker container did not complain about the permissions and it was able to create new folders inside the cache folder. Not sure why that worked, but it did.

CT-275555 commented 3 months ago

When encounterd this error I went to try and make the file manualy only to find that it was already there but it had the UID:GID as root:root so I just manualy changed them to the correct ones with sudo chown -R 1000:998 navidrome and that seemed to fix the issue

codenamek83 commented 3 months ago

After redeploying Navidrome today using the same docker-compose setup, everything is now functioning correctly. Here are the key points:

The container is now running rootlessly with the user set to 1000:1000.
Both the data and cache are stored on their respective bind-mounts.

This solution effectively prevents unnecessary cache file exports to my backup repository on a daily basis. For those who initially deployed the container with root access, I recommend considering a redeployment using a user account instead. Just ensure that the user account has appropriate access to all bind mounts at the host level.

deluan commented 2 months ago

Hey @conartist6 , were you able to figure this out? Can we close this?

mlazzarotto commented 2 weeks ago

So the solution would be to remove user: 1000:1000 from the docker compose? What's the impact of this?

codenamek83 commented 2 weeks ago

So the solution would be to remove user: 1000:1000 from the docker compose? What's the impact of this?

Not necessary to remove the user: 1000:1000.

navidrome / navidrome