I'm on Ubuntu 20.04, and I just saw something that I was never aware of so far.
I wanted to get and https://github.com/mifi/lossless-cut; however, I do not have space on my primary ext4 formatted disk drives; however, I have space on an NTFS partition, and a NFS network share. Turns out, I cannot get AppImage to run on either of these.
First, I got it on the NTFS drive:
$ cd /media/user/ntfsdrive
$ wget https://github.com/mifi/lossless-cut/releases/download/v3.53.0/LosslessCut-linux-x86_64.AppImage
$ ls -la | grep LosslessCut
-rw-rw-rw- 1 user user 160191288 Mar 10 15:09 LosslessCut-linux-x86_64.AppImage
Trying to set the executable bit on an NTFS partition will not work:
$ chmod +x LosslessCut-linux-x86_64.AppImage
$ ls -la | grep LosslessCut
-rw-rw-rw- 1 user user 160191288 Mar 10 15:09 LosslessCut-linux-x86_64.AppImage
So, I won't be able to run LosslessCut from this location. Note that this partition is:
$ mount | grep ntfsdrive
/dev/sda6 on /media/user/ntfsdrive type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,x-gvfs-show)
... but I guess the following holds for it as well https://superuser.com/questions/1578345/how-to-set-un-executable-permission-for-the-file-in-ntfs-partition-in-linux :
By default the ntfs-3g driver ignores the actual NTFS permissions and always shows fixed values (like the vfat driver). You can change those using the mount options
fmask=0133,uid=1000, etc.
So, I could either make ALL files on the NTFS partition executable (which I do not want) and run the AppImage in that way - or I cannot run this AppImage from this partition.
I was hoping, I could "cheat" the executable bit thing, by using the loader directly ( found the approach here: https://dtrugman.medium.com/elf-loaders-libraries-and-executables-on-linux-e5cfce318f94 ):
$ bash -x $(which ldd) LosslessCut-linux-x86_64.AppImage 2>&1 | grep LosslessCut | grep ld
++ /lib/ld-linux.so.2 --verify ./LosslessCut-linux-x86_64.AppImage
++ /lib64/ld-linux-x86-64.so.2 --verify ./LosslessCut-linux-x86_64.AppImage
$ /lib/ld-linux.so.2 ./LosslessCut-linux-x86_64.AppImage
./LosslessCut-linux-x86_64.AppImage: error while loading shared libraries: ./LosslessCut-linux-x86_64.AppImage: wrong ELF class: ELFCLASS64
$ /lib64/ld-linux-x86-64.so.2 ./LosslessCut-linux-x86_64.AppImage
./LosslessCut-linux-x86_64.AppImage: error while loading shared libraries: ./LosslessCut-linux-x86_64.AppImage: ELF file ABI version invalid
$ file LosslessCut-linux-x86_64.AppImage
LosslessCut-linux-x86_64.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, stripped
Eh, weird - especially that if I move the LosslessCut-linux-x86_64.AppImage to my home directory and make it executable, ./LosslessCut-linux-x86_64.AppImage runs, no problem. (although the above errors persist even when the file is in home dir).
Right, so I cannot get anywhere with the NTFS partition, so I'm trying the NFS network share:
$ mv LosslessCut-linux-x86_64.AppImage /media/user/nfsshare
$ cd /media/user/nfsshare
$ chmod +x LosslessCut-linux-x86_64.AppImage
$ ls -la LosslessCut-linux-x86_64.AppImage
-rwxrwxrwx 1 user user 160191288 Mar 10 15:09 LosslessCut-linux-x86_64.AppImage
Ah, there we go - executable permission bits are set; so we can just run it, right?
$ ./LosslessCut-linux-x86_64.AppImage
bash: ./LosslessCut-linux-x86_64.AppImage: Permission denied
... ehh, no. And I don't really get this "Permission denied", given I'm the owner of the files, and permissions are 777; only other such situation I've encountered is when I'm trying to run say 32-bit executable on my 64-bit system - but this file runs, if it is located in $HOME! So that cannot be it ...
Finally, I moved the file to $HOME, but there was this weirdness:
$ mv LosslessCut-linux-x86_64.AppImage ~/
$ ~/LosslessCut-linux-x86_64.AppImage
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
So, if the AppImage (with 777 permissions) is in $HOME, but current working directory is an NFS share, then I cannot run the AppImage anyways, because now some .so file is not found? But then, if I change working directory, and try to run the program:
$ cd ~
$ ./LosslessCut-linux-x86_64.AppImage
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
... it finally runs (though there is no indication of that here, as only the "libva error:" message is printed).
What an adventure! /s
So, my questions are:
- Are there any restrictions inherent in the AppImage format, that limit where (and on what filesystem) an AppImage can run from, similar to how
snapheavily restricts its applications by default? - Are there any workarounds that would allow me to have the AppImage file being located on either an NTFS partition or NFS share, and still be able to run it?
- Note, there is one workaround: create a big disk image file on either NTFS partition or NFS share, format it as
ext4, then mount it; then move the AppImage file there, and give it executable permissions - it should run. However, then the AppImage is "hidden" in the disk image; and I'd like it to be "present" directly on the filesystem.
- Note, there is one workaround: create a big disk image file on either NTFS partition or NFS share, format it as
