Type in your question below and we'll check to see what answers we can find...
Loading article...
Submitting...
If you couldn't find any answers in the previous step then we need to post your question in the community and wait for someone to respond. You'll be notified when that happens.
Simply add some detail to your question and refine the title if needed, choose the relevant category, then post.
Before we can post your question we need you to quickly make an account (or sign in if you already have one).
Don't worry - it's quick and painless! Just click below, and once you're logged in we'll bring you right back here and post your question. We'll remember what you've already typed in so you won't have to do it again.
Please see below the most popular frequently asked questions.
Loading article...
Loading faqs...
Please see below the current ongoing issues which are under investigation.
Loading issue...
Loading ongoing issues...
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.
Solved! Go to 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 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:
Please add the plugin for external drives. Thank you.
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
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.
Thank you so much but is... TOO MUCH!
https://open.spotify.com/track/2j0zExWFB0PowLOeoZosjK?si=09f44a33734a4d0b
Hey there you, Yeah, you! 😁 Welcome - we're glad you joined the Spotify Community! While you here, let's have a fun game and get…