Problem accessing files with symlinks

Applications
1

I’m using Gimp 3.0.4 on Ubuntu 24 and I have trouble using files with symbolic links (symlinks) in their path. For instance, I have a large disk that’s separate from the boot disk. I put many of my files there and use symlinks to make things for seamless for me. For example, I keep a lot of Github repos in my ~/repos directory but it’s really a symlink to a repos directory in the other disk:

$ ls -ld ~/repos
lrwxrwxrwx 1 mrbruno mrbruno 18 Apr 16  2023 /home/mrbruno/repos -> /ExtraVolume/repos
$ ls -Lld ~/repos
drwxrwxr-x 15 mrbruno mrbruno 4096 Nov  9  2024 /home/mrbruno/repos
$ ls -ld /ExtraVolume
drwx------ 16 mrbruno mrbruno 4096 Sep 24  2023 /ExtraVolume
$ df /ExtraVolume
Filesystem      1K-blocks      Used  Available Use% Mounted on
/dev/sda1      1921724608 153991980 1670040572   9% /ExtraVolume
$ mount | grep ExtraVolume
/dev/sda1 on /ExtraVolume type ext4 (rw,nosuid,nodev,relatime)
$ ls ~/repos | wc
     14      15     176
$ find ~/repos -follow -name \*.png | wc
     29      35    1717
$

The problem is I can’t open ~/repos in Gimp to access images in a Github repo:

image
image348×174 11.8 KB

I agree it’s not a regular file - it’s a symlink which resolves to a directory.

I thought I could use the real path but Gimp doesn’t find /ExtraVolume in the root directory:

image
image798×783 62.7 KB

Are these bugs in Gimp? Can anyone suggestion a workaround?

2

How did you install GIMP? Is it containerized (e.g. flatpak, appimage maybe)? If so, GIMP won’t be able to read data in /ExtraVolume by default unless you grant the container access to it. A symbolic link does not bypass that security :slight_smile:

3

It’s not in a container. It’s installed via snap.

4

Snap is a container. Even more to the topic, it’s a sandbox (what GIMP sees is not necessarily the same file tree which you see). For instance AppImage may in fact not have this problem (because it is not a sandbox by default, though it may be one, with specific additional settings, AFAIU). Flatpak would have the same issue.

Unless /ExtraVolume is some generic folder in Ubuntu (in which case, you could ask the snap maintainers what they think of adding this folder in the list — if that makes sense), there is probably not much to be done on both GIMP or the packagers side (if this is a custom mount, which is what I guess it is, it can’t be taken into account in package rules). But maybe Snap has a way to edit file system rules on a case-by-case basis (Flatpak has this ability through the command line, or again with the Flatseal GUI software).

The real solution will be when we will implement the native file dialog portal. It will happen eventually, though this comes with its own challenges.

5

As everybody above.

However, if instead of a symlink you use a “bind-mount” it will probably work.

1 Like
6

Ok, I never associated snap with containers. My mind immediately went to Docker and I knew I didn’t have a gimp container in Docker.

Thanks for the information.

7

Thanks! A bind mount worked!

1 Like