Problem Loading Thumb Previews:
This started to happen after upgraded Ubuntu from 12.04 to 12.10.
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.
Sign up to join this communityProblem Loading Thumb Previews:
This started to happen after upgraded Ubuntu from 12.04 to 12.10.
try changing nautilus preferences
Edit-> Preferences-> Preview-> Other Previewable Files-> only files under (set a higher MB value and then try reloading)
This may happen if you get a different UID from the one you had before (this will remove you the ownership of those files). Try executing this on a terminal:
sudo chown -R $USER:$USER ~/.thumbnails
From 12.10 onward, thumbnais are also stored in ~/.cache/thumbnails
, so you may repeat the same process for this location.
If none of those solves your issue, you can always remove them (they are automatically generated, and I think failed thumbs generations are cached):
sudo rm -rf ~/.thumbnails/* ~/.cache/thumbnails/*
Note: it's not the case of OP, but if you don't get previews to video files (ex: mkv, mp4) probably you are missing the video codec. This can be easily fixed by open the video with "Movie Player": it will propose a suitable codec.
mkdir ~/.thumbnails
, then logout/login.
sudo chown -R $USER:$USER ~/.cache/thumbnails
worked for me on Ubuntu 18.04., but I also needed to first enlarge the size of the thumbnails (ctrl + mouse wheel)
I had the same issue.
I solved it by moving the .thumbnails folder and setting a symbolic link to .cache/thumbnails instead.
mv ~/.thumbnails ~/thumbnails
ln -s ~/.cache/thumbnails ~/.thumbnails
Is it possible that there were some changes?
It looks to me like the thumbnailers create their thumbnails in .cache/thumbnails, while nautilus keeps looking in .thumbnails.
Looks like the path has changed in recent versions. For me the issue in 13.04 was that ~/.cache/thumbnails
was owned by root
.
So for 13.04 at least, the command is:
sudo chown -R yourusername:yourusername ~/.cache/thumbnails
So Salem did have it-
If you are trying to access a network device like a NAS, then go to nautilus preferences, and choose Edit-> Preferences-> Preview-> Other Previewable Files->Show thumbnails->Always
Hope this helps!
there may be another factor causing this - perhaps you didn't install the right codec as suggested here: http://iwillfolo.blogspot.co.il/2013/10/thumbnail-doesnt-load.html
try installing ubuntu restricted extras. Open a terminmal and type:
sudo apt-get install ubuntu-restricted-extras -y
Depends on version of glib, the change was in the Gio module starting in the 2.35 series.
The thumbnail cache directory is prefixed with $XDG_CACHE_DIR/
and the leading dot removed (since $XDG_CACHE_DIR
is normally $HOME/.cache
). The glib ChangeLog indicates the path for large sizes was "fixed" (Added $XDG_CACHE_DIR
)
starting with 2.35.3 so as to match the path for normal sizes, implying some versions using the added prefix, pior to 2.35.3 (I did not find any) are broke. The solution to add the symbolic link would provide a work-around for these broken versions.
In my case it was pretty simple: All I had to do is to change the preference in nautilus, by switching from "show thumbnails: only local files" to "show thumbnails: always" (my JPGs located in my smartphone weren't being shown). I found the issue thanks to Aswn, practically, so thumbs up for him/her.
Change nautilus preferences in
Edit
-> Preferences
-> Preview
-> Files
-> Show Thumbnails
from "Local files Only" to "Always". This could be helpful for usb memories or any external source like phones.
(ubuntu 14.04 LTS)
I had the same symptom and fixed it by installing the following package
sudo apt install libgdk-pixbuf2.0-bin
In my case I disabled a kernel sysctl setting because of CVE-2022-32250 and this broke "bwrap" from package bubblewrap which is used internally when creating thumbnails!
So the following as "root" made it work again for me:
echo "1" > /proc/sys/kernel/unprivileged_userns_clone
Unfortunately the actual error messages in nautilus is hidden deeply inside so that only running with strace allowed to find out the "bwrap" commandline which then showed the proper error-message.