Announcements

Help Wizard

Step 1

NEXT STEP

FAQs

Please see below the most popular frequently asked questions.

Loading article...

Loading faqs...

VIEW ALL

Ongoing Issues

Please see below the current ongoing issues which are under investigation.

Loading issue...

Loading ongoing issues...

VIEW ALL

[LINUX] Permission denied: Cannot change offline songs storage/local files directory

Solved!

[LINUX] Permission denied: Cannot change offline songs storage/local files directory

Plan

Premium

Country

Germany

Operating System

Linux Mint 19.1

Version

1.1.0.237.g378f6f25

My Question or Issue

I have an NTFS drive mounted as /mnt/data. The folder has 777 permissions and I can write/read normally from the drive. Spotify reports permission denied everytime I try to access these drives for storage/local files location. 

 

Here's some output from the terminal:

ln: failed to create symbolic link '/home/jogerj/snap/spotify/34/.config/gtk-2.0/gtkfilechooser.ini': File exists
Gtk-Message: Failed to load module "gail"
Gtk-Message: Failed to load module "atk-bridge"
[0424/231319.879328:ERROR:object_proxy.cc(615)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.181" (uid=1000 pid=28418 comm="/snap/spotify/34/usr/share/spotify/spotify " label="snap.spotify.spotify (enforce)") interface="org.freedesktop.DBus.Properties" member="Get" error name="(unset)" requested_reply="0" destination="org.freedesktop.UPower" (uid=0 pid=1554 comm="/usr/lib/upower/upowerd " label="unconfined")
[0424/231319.879470:ERROR:object_proxy.cc(615)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.181" (uid=1000 pid=28418 comm="/snap/spotify/34/usr/share/spotify/spotify " label="snap.spotify.spotify (enforce)") interface="org.freedesktop.UPower" member="GetDisplayDevice" error name="(unset)" requested_reply="0" destination="org.freedesktop.UPower" (uid=0 pid=1554 comm="/usr/lib/upower/upowerd " label="unconfined")
[0424/231319.879629:ERROR:object_proxy.cc(615)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.181" (uid=1000 pid=28418 comm="/snap/spotify/34/usr/share/spotify/spotify " label="snap.spotify.spotify (enforce)") interface="org.freedesktop.UPower" member="EnumerateDevices" error name="(unset)" requested_reply="0" destination="org.freedesktop.UPower" (uid=0 pid=1554 comm="/usr/lib/upower/upowerd " label="unconfined")
[0424/231329.308569:ERROR:gl_context_glx.cc(227)] Couldn't make context current with X drawable.
[0424/231329.308617:ERROR:gles2_cmd_decoder.cc(4575)]   GLES2DecoderImpl: Context lost during MakeCurrent.
[0424/231329.309156:ERROR:gles2_cmd_decoder.cc(4570)]   GLES2DecoderImpl: Trying to make lost context current.
[0424/231329.309347:ERROR:gl_context_glx.cc(227)] Couldn't make context current with X drawable.

On the other hand I wanted to use the apt version of Spotify but that too crashes every so often.

Reply

Accepted Solutions
Marked as solution

Raising this thread again since it still comes up top on a search for "spotify linux local files permission denied"

 

The suggestions in the link @jooon offered do not/no longer work since the only directory Spotify can access under $HOME is /home/<user>/snap/spotify and the Spotify snap is packaged as "strict" confinement.

See: https://forum.snapcraft.io/t/snap-confinement/6233 if interested.

I'm not sure what went wrong with the "spotify:home" connection/interface not actually providing access to all of the user's home directory but it seems like that is broken one way or another.


So option 1 results in a new mount point that Spotify still cannot access and option 2 results in snap installing Spotify but with the message:

 

 

 

Warning: flag --classic ignored for strictly confined snap spotify

 

 

 


However, if you're finding this in 2021+, @jooon's suggestion to use a bind mount is still close to what you need. We just need to mount the external targets into a space Spotify can already see. Hopefully this guide will be useful even if you don't know what containers or bind mounts are.


To get both the cache where you want it and local music files working:

* Open Spotify > preferences
    * Show advanced settings
    * Check "Offline storage location" points to /home/<username>/snap/spotify/common/.cache/spotify/Storage
    * Change it if you want, just make sure it matches your bind mount.
* Close Spotify
* Run this in a terminal:

 

 

 

cd $HOME/snap/spotify/common
mkdir .local
sudo mount --bind /wherever/you/want/offline_files/actually/stored/ .cache/spotify/Storage/
sudo mount --bind /path/to/your/local/files/ .local/

 

 

 

* Open Spotify > preferences
* Switch on local files and add a source
    * other locations > computer /home/<username>/snap/spotify/common/.local > open
    * You should now see your local files in "Your Library" > Local Files
* Right-click your previously downloaded playlists and select "Download"
* You should see them "download" ridiculously quick and the "Your library" progress bar go through the file count fast. (if it goes slow, Spotify is re-downloading instead of just realizing that your songs are already indexed)
    * If you don't see any of your known-previously-downloaded stuff getting indexed immediately, either you got the bind mount wrong or the Offline Storage location is not pointed at the folder you did bind to.
    * If only some stuff registers immediately but other stuff downloads again anyway, that happened to me too. ¯\_(ツ)_/¯

        * This might just be that you also need to bind mount the ~/snap/spotify/common/.cache/spotify/Data folder in addition to the Storage folder. I'm not sure where the overlap is or why Spotify settings doesn't mention it but there's at least as much data in the Data folder as the Storage folder and they both get updated on playlist downloads.

 

Once you know the mounts are working you can make them permanent by following instructions here: 

* https://serverfault.com/questions/613179/how-do-i-do-mount-bind-in-etc-fstab

* Just add lines to /etc/fstab for each folder matching the pattern:

 

 

 

/source /destination none defaults,bind 0 0

 

 

 

    * Reboot and check the folders/Spotify behavior again to make sure your mounts stuck.

* Do not follow the instructions here: https://askubuntu.com/questions/550348/how-to-make-mount-bind-permanent

(Which is what you will likely find on a search for this idea.)

        * That will most likely lead to your system crashing into maintenance mode on restart.

        * If that happens, don't panic. Nothing got wrecked, your entries just failed to mount and linux takes mount failures very seriously. 😏

        * Just follow the instructions on screen to get to a command prompt. Then edit /etc/fstab to remove the new entries you added. Reboot. Try again.

   

 

This worked for me running dual-boot Kubuntu on an ext4 main drive partition binding the offline storage to an NTFS secondary drive with existing files from a Win10 install and local files on an exFat secondary drive.


If you want to know why bind mounts work for this and soft links don't see: https://unix.stackexchange.com/questions/198590/what-is-a-bind-mount
In particular, the top answer's segment on "Mounting in a jail or container".

View solution in original post

8 Replies

The reason you have this problem is that the snap installed spotify runs in a sandbox, but the user interface is bad, because it doesn't clearly tell our users that.

 

Until this can be fixed properly, by opening up access from the sandbox on the fly from a user request, there are two workarounds listed here:

https://community.spotify.com/t5/Desktop-Linux/Ubuntu-How-to-change-Offline-songs-storage-folder-to-...

Please add the plugin for external drives. Thank you.

 

This ^^^

I tried with a symbolic link from my old folder in "home" to my drive in "/mnt/data". But it doesn't work either.

 

mv /home/ramon/snap/spotify/common/.cache/spotify  /mnt/data/

ln -s /mnt/data/spotify  /home/ramon/snap/spotify/common/.cache/spotify

 

 

Will this work in Linux Mint 20?
Marked as solution

Raising this thread again since it still comes up top on a search for "spotify linux local files permission denied"

 

The suggestions in the link @jooon offered do not/no longer work since the only directory Spotify can access under $HOME is /home/<user>/snap/spotify and the Spotify snap is packaged as "strict" confinement.

See: https://forum.snapcraft.io/t/snap-confinement/6233 if interested.

I'm not sure what went wrong with the "spotify:home" connection/interface not actually providing access to all of the user's home directory but it seems like that is broken one way or another.


So option 1 results in a new mount point that Spotify still cannot access and option 2 results in snap installing Spotify but with the message:

 

 

 

Warning: flag --classic ignored for strictly confined snap spotify

 

 

 


However, if you're finding this in 2021+, @jooon's suggestion to use a bind mount is still close to what you need. We just need to mount the external targets into a space Spotify can already see. Hopefully this guide will be useful even if you don't know what containers or bind mounts are.


To get both the cache where you want it and local music files working:

* Open Spotify > preferences
    * Show advanced settings
    * Check "Offline storage location" points to /home/<username>/snap/spotify/common/.cache/spotify/Storage
    * Change it if you want, just make sure it matches your bind mount.
* Close Spotify
* Run this in a terminal:

 

 

 

cd $HOME/snap/spotify/common
mkdir .local
sudo mount --bind /wherever/you/want/offline_files/actually/stored/ .cache/spotify/Storage/
sudo mount --bind /path/to/your/local/files/ .local/

 

 

 

* Open Spotify > preferences
* Switch on local files and add a source
    * other locations > computer /home/<username>/snap/spotify/common/.local > open
    * You should now see your local files in "Your Library" > Local Files
* Right-click your previously downloaded playlists and select "Download"
* You should see them "download" ridiculously quick and the "Your library" progress bar go through the file count fast. (if it goes slow, Spotify is re-downloading instead of just realizing that your songs are already indexed)
    * If you don't see any of your known-previously-downloaded stuff getting indexed immediately, either you got the bind mount wrong or the Offline Storage location is not pointed at the folder you did bind to.
    * If only some stuff registers immediately but other stuff downloads again anyway, that happened to me too. ¯\_(ツ)_/¯

        * This might just be that you also need to bind mount the ~/snap/spotify/common/.cache/spotify/Data folder in addition to the Storage folder. I'm not sure where the overlap is or why Spotify settings doesn't mention it but there's at least as much data in the Data folder as the Storage folder and they both get updated on playlist downloads.

 

Once you know the mounts are working you can make them permanent by following instructions here: 

* https://serverfault.com/questions/613179/how-do-i-do-mount-bind-in-etc-fstab

* Just add lines to /etc/fstab for each folder matching the pattern:

 

 

 

/source /destination none defaults,bind 0 0

 

 

 

    * Reboot and check the folders/Spotify behavior again to make sure your mounts stuck.

* Do not follow the instructions here: https://askubuntu.com/questions/550348/how-to-make-mount-bind-permanent

(Which is what you will likely find on a search for this idea.)

        * That will most likely lead to your system crashing into maintenance mode on restart.

        * If that happens, don't panic. Nothing got wrecked, your entries just failed to mount and linux takes mount failures very seriously. 😏

        * Just follow the instructions on screen to get to a command prompt. Then edit /etc/fstab to remove the new entries you added. Reboot. Try again.

   

 

This worked for me running dual-boot Kubuntu on an ext4 main drive partition binding the offline storage to an NTFS secondary drive with existing files from a Win10 install and local files on an exFat secondary drive.


If you want to know why bind mounts work for this and soft links don't see: https://unix.stackexchange.com/questions/198590/what-is-a-bind-mount
In particular, the top answer's segment on "Mounting in a jail or container".

The Mint team dislikes snap and specifically decided to make it harder for you to use snap apps.

If you installed Spotify through your package manager, this permissions issue shouldn't be a problem for you.

 

If you installed snap anyway and then went on to install Spotify with it, then you likely have the same problem as anyone else using snap packages. In that case, see my post above, the process for binding a mount into the container space should be the same for you.

Suggested posts