RAW thumbnails on remote NAS

Hi guys,

Got a strange problem. I cannot see thumbnails from RAW (CR2) files in Dolphin (or other file managers).

However, all other media files work, even bigger files (MP4). So doesn’t seem to be a size issue.

And on top of that, thumbnails of RAW files works fine when they are stored locally.

Haven’t found this issue anywhere I looked, so hoping for some help here.

Check the file manager settings - look for something like

[ ] Show thumbnails of files
[ ] Only show thumbnails of local files
Do not generate thumbnails for files exceeding this size size KB

Thanks for the reply. All those settings are correct. It does provide thumbnails for all other than raw remote. Even files larger than the raws.

My setup.
Dolphin Preferences > General > Previews. At the bottom, entries for
“Skip previews for local files above” and “Skip previews for remote files above”
Check the size of the RAW files and set that figure above that size, in my case it took 30MiB before the Thumbnails were displayed (Canon 18Gb Camera).
You will need to close and re-open Dolphin for this to take effect.

I remember having this issue too, but with Nemo. In my case it turned out that the huge file size was the culprit: took (relatively) long to transfer and process, which I, in my haste, mistook for thumbnails not working. Apparently it’s easy to extract a thumbnail from a video file, because that always was fast enough for me.

Manjaro 21.1.2
KDE Plasma Version: 5.22.5
Kernel Version: 5.14.0-0-MANJARO (64-bit)
Graphics Platform: X11

I’m having the same problem described here: RAW thumbnails on remote NAS

CR2 (Canon raw) files stored on Windows shares can’t be previewed as thumbnails in Dolphin. Doesn’t matter if the connection is wi-fi or wired. On the computer’s local drive Dolphin displays CR2 thumbnails just fine. And thumbnails for other graphics formats display fine both locally and remotely.

No problem opening remote CR2 files in Gwenview via Dolphin. Gwenview even creates and displays thumbnails that end up in the user’s .cache/thumbnails directory.

Briefly I thought I had it solved by doing what worked for Ubuntu. Adding the image/x-canon-cr2; mime type to the end of –

/usr/share/thumbnailers/gdk-pixbuf-thumbnailer.thumbnailer

and restarting Dolphin seemed to have fixed it but only temporarily for a directory of images accessed repeatedly. If that actually helped at all it didn’t persist and a batch of remote thumbnails that displayed yesterday are gone today.

Lastly, Dolphin is configured to skip remote previews with a very generous size limit.

Any ideas on what to try next?

I don’t use CR2 / RAW, but do have large video files and I’ve set both local and remote to 1GB and haven’t had any problems since:

:thinking:

That’s the first thing I checked and my config is identical to yours. I tried larger limits but no dice. CR2 thumbnails display almost instantly on the local drive.

I do wait and wait but time is no help. In fact, Dolphin can’t produce thumbnails for remote directories containing only two or three CR2 files no larger than 28 Mb each. Wi-fi throughput can be frustraing at times but a patch cord made no difference.

1 Like

Grasping at straws now, but could you:

  • remove CR2 in the Show previews in the view for: list, then click Apply, then set it again and click Apply again? (all the while keeping 1GB for both local and remote)
  • If that doesn’t work, can you create a new user, log in there and try there the above as well?

:thinking:

1 Like

Just to make sure, thumbnails are generated and stored from a remote share for everything except RAW? JPEG, PNG, MP4, etc, on a remote share generate and store thumbails?

The reason I ask is because Dolphin incorporates some “security” features to mitigate against “leakage”.

It’s known that Dolphin will not cache thumbails from an external encrypted device, such as a USB drive. (This is intentional design.) Their rationale is that “cache” lives locally, and thus these thumbails will reveal sensitive/private/secret images that are assumed to be protected through encryption on the external device.

Perhaps Dolphin is applying a similar technique for remote/network shares?

:thinking:

I might have figured it out.

I just tested Dolphin with CR2 files, and here’s what I discovered:

  • :white_check_mark: Thumbnails work if file lives locally

  • :white_check_mark: Thumbnails work if file lives on SMB share, accessed via the traditional cifs protocol

  • :x: Thumbails do not work if file lives on SMB share, accessed via Dolphin’s smb://


In order to mount an SMB share with the traditional (and faster, more preferred) cifs protocol:

  • Use Smb4K to manage, bookmark, and configure such network shares
    or
  • Invoke it in the command line with mount and -t cifs
    or
  • Add an entry for it in the fstab
    or
  • Use a systemd unit

I hate to sound like a broken record, but I must emphasize that if you use network shares (SMB) regularly in KDE, the Smb4K manager streamlines the process and keeps things organized and readily accessible. No need to use the terminal or fstab or systemd units.

It’s available in the official repositories and it’s considered part of the KDE ecosystem.

4 Likes

Thanks @Fabby but the problem persists after trying both suggestions.

Yes, that’s right. JPEG, PNG, BMP, video formats and even huge TIFF files have remote thumbnails in Dolphin. Only CR2 is a problem. I can’t try other raw formats like CR3, DNG and Nikon RAW until my photographer friends send samples.

Makes sense for protecting encrypted drives but my LAN is plain vanilla NetBIOS sharing with native NTFS.

That’s my scenario in a nutshell.

Sounds great because Smb4K manager isn’t something I knew about. I will report back with results asap. Is this package Ok on top of the manjaro-samba-settings package or would that be redundant?

Awesome detective work! Thanks!

1 Like

They’re enirely separate and have nothing to do with each other.

Smb4K is its own thing, and it uses the cifs mount protocol.

You might have to play around with some settings before you rule it out.


For one, it depends on the server (TrueNAS, Synology, Windows 10, etc) and which version of SMB it’s running. Usually, Smb4K defaults to negotiating the highest version between client and server.

Secondly, make sure you understand how permissions are translated, and why you should not use the “Unix extensions.” (They require you to drop to a slower and less secure version of SMB. Not worth it in my opinion. Smb4K leaves it disabled by default.) :+1:

For the most part, the defaults work as expected.

I do, however, highly suggest that you change the default mount prefix to live outside of your user’s home folder.

I personally use /home/smb4k/

Other alternatives can be /mnt/smb4k/ or /media/smb4k/

The reason for this is you don’t want programs to “walk across” your SMB shares when you run commands on your user’s home folder. For example: rsync, ls, find, cp, scans, etc.

Make sure to create the directory with sudo to have it ready:

sudo mkdir -p /home/smb4k

or

sudo mkdir -p /mnt/smb4k

or

sudo mkdir -p /media/smb4k

Then you can configure the mount prefix option in Smb4K under ConfigureMounting


EDIT: And for good measure, exclude the path in Timeshift, just to err on the side of safety.

3 Likes

:angry: :stuck_out_tongue_winking_eye:

:+1: :clap:

Why you ask? Because of this:

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

1 Like

@Fabby & @winnie,

I struggled with Smb4k and couldn’t get it working. With more study and tampering I’ll try again another day. I feel somewhat like a dullard not knowing about Smb4k until today. It wasn’t ever needed before.

However! There’s progress on the original topic. Shares are cifs mounted with fstab and wuddayaknow – CR2 thumbnails! As a bonus my buddy’s CR3s show up too. And load times are snappier than I was expecting.

Knowing the cause I consider the case solved. Thanks again for all your help. It’s been an educational day.

:+1:

That’s why I always encourage users to use one of the following four methods. (The first being applicable only for KDE.)

Let me know what hurdles or confusions you bumped into with Smb4K and we might be able to get it working. :slight_smile:

2 Likes

I use the reverse order that Winnie uses, but then, I’m a psychopath I don’t like the computer figuring out things for me automatically and use manual mounts for all often-used external media, including my own USB sticks because then me, myself and I have control over what’s happening…

When someone else hands me a USB stick/SSD/HDD, I still let it figure things out automatically…

:crazy_face:

I may go with manual mounts also as long as I’m mounting with fstab because the laptop takes longer to shut down now (one of my favorite Manjaro features is no delay shutting down, unlike other KDE distros). Before the first reboot I tested with manual mounts without errors and decent networking. Then at first the computer was hanging during shutdown and start which was a bit nerve wracking. After a couple more recycles booting came back to normal but shutting down is still slower, but at least the hanging stopped. I probably need to tweak my fstab lines a bit more including a credentials file.

Provide us with what you currently have in fstab: we’ll probably be able to help…

:innocent:

I reckon delayed shutdown is a case of extra time dismounting, expecially if the Windows computer nodded off; and a sleepy Windows computer probably accounts for any slowness while booting. i.e., Just like my workgroup printer queue. :yawning_face:

Anyway, I’m connecting to two shares on two separate drives. These mounts succeed over all but I’m unsure about the x-systemd.automount part – if removing that will allow cleaner restarts and manual mounting.

//192.168.1.130/users /mnt/samba1 cifs username=win10user,password=*****,domain=workgroup,uid=linuxuser,gid=linuxuser,x-systemd.automount,user 0 0
//192.168.1.130/storage /mnt/samba2 cifs username=win10user,password=*****,domain=workgroup,uid=linuxuser,gid=linuxuser,x-systemd.automount,user 0 0

I do plan to move credentials to a separate file in /home.