RAW thumbnails on remote NAS

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.

Even on my Manjaro Xfce system, I experience the same “frozen / delayed” shutdowns when I use the fstab method to mount SMB shares. However, if I manually unmount the share first, then the shutdown sequence is nearly immediate.

I get hit with a double-whammy if there is a network disruption before unmounting the share, as the system “chokes” since it doesn’t have an active network connection to properly “disconnect”?

Honestly, it’s very odd, and desktop Linux has yet to catch up to Windows when it comes to accessing SMB network shares. (GVFS and KIO-fuse are very slow and primitive compared to proper standard mounts, yet the latter yields strange issues when suspending, rebooting, or shutting down.) In fairness, SMB is a Microsoft technology. :wink:

It’s for this reason why I shy away from using a static fstab entry for dynamic/network shares.

An alternative approach can be to use systemd mount units or the older legacy method of automount. Both I believe expose your password either in the command itself or by storing it in the plain in a hidden/secret file (which you alluded to.) This is another reason I like using Smb4K, since you can configure it to either (1) always prompt for the passphrase, (2) store the credentials in an encrypted KDE Wallet, or (3) store the credentials in a plaintext file. (I use method #1).


You would think if there’s an fstab entry for the SMB share, then the shutdown sequence will automatically and safely unmount it. Perhaps you’re experiencing a “choke” if the system disconnects from the network before unmounting the share? Perhaps there’s a way to instruct it to unmount the filesystems/shares before disconnecting from the network and/or halting the network service?

1 Like

Can you change x-systemd.automount to:

noauto,x-systemd.automount,x-systemd.device-timeout=10

That way:

  • noauto = the systemd mount will not be mounted by fstab, but at first use
  • 10 = even if stuck, it will bail out after 10 seconds.

so that will:

  • not make your boot-up longer BUT will make the browsing slower when you first open that directory.
  • will add a maximum of 10 seconds to your shutdown even if you shut down the Windows machine / NAS / … before the Manjaro one.

:grin:

P.S. I’ve never bothered optimising the time-out below 10 seconds, but I’m pretty sure that if you test things out, you’ll be able to shave off a few to many seconds depending on your specific hardware / network.

2 Likes

Yeah, over the years I’ve come to accept these kinds of imperfetions and I’m at peace with it. I figure the closest thing to higher quality networking is Linux everywhere with Windows in the rearview. Easier said than done, especially for us old timers who cut their teeth on Netware and Windows NT.

Linux on the desktop may have catching up to do but Windows 10 has networking problems that are too unique for words. For stabler throughput I’ve come to trust Linux-to-Windows more than Windows-to-Windows. The former is mostly stable despite all the Samba hoops we jump through. To break the latter’s connection all I need to do is copy a Linux ISO. File dumps between two Windows 10 machines is so bad (audience: “How bad is it?”)… It’s so bad I’ve been tempted to dig up and install NetBEUI just for grins if not for its robust transport.

Smb4k is on my todo list. I’ll start a fresh new post when questions come up. In the meantime I don’t mind the fstab method manually or automated (thanks for the unmount before boot tip, btw). I need to make sure external apps can browse the mounted shares. If that becomes a problem I’ll be ready for another round with Smb4k sooner rather than later.

This is fabby-lous! It all seems to be working but more time is needed to spot problems. So far so good. Many thanks!

Please, please, please don’t forget to come back to your question after your issue has been solved and click the 3 dots below the answer to mark a solution like this below the answer that helped you most:
Solution
so that the next person that has the exact same problem you just had will benefit from your post as well as your question will now be in the “solved” status.

:pray:

I’ve marked this answer as the solution to your question as it is by far the best answer you’ll get.

However, if you disagree with my choice, please feel free to take any other answer as the solution to your question or even remove the solution altogether: You are in control! (If you disagree with my choice, just send me a personal message and explain why I shouldn’t have done this or :heart: or :+1: if you agree)

:innocent:
P.S. In the future, please don’t forget to come back to your question after your issue has been solved and click the 3 dots below the answer to mark a solution like this below the answer that helped you most:
Solution
so that the next person that has the exact same problem you just had will benefit from your post as well as your question will now be in the “solved” status.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.