The pre-built application I am trying to Snap is aware of the file system and available disk space. Since Snaps use squashfs, the used & available space is the same which indicates to the app that there is no available disk space.
Is there a common workaround for this issue or is this a blocking issue for apps that check available disk space before launching?
It seems possible, see for example:
You probably need the proper plug to access a resource outside of the confinement:
Not sure which ones though, I don’t have experience with that kind of requirements.
How does your application detect usable file space? If you are using df, it seems to report the right size of my disks in /dev, i.e.
$ my-snap-name.df -h /dev/nvme0n1p1
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p1 915G 323G 546G 38% /etc
This is with the mount-observe interface connected.
Presumably it is running statvfs on some path and checking f_bavail for available space. If it has picked a location on a squashfs file system (e.g the / provided by the base snap) then it will think there is no space available. If run against a path the snap can write to, it should get reasonable information.
For example, using the Chromium snap’s sandbox to demonstrate:
$ snap run --shell chromium
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ python3
Python 3.6.9 (default, Nov 7 2019, 10:44:02)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.statvfs('/').f_bavail
0
>>> os.statvfs(os.environ['SNAP_USER_DATA']).f_bavail
120804954
>>>
So the answer is that the app should check the path it actually wants to write to: checking other paths might appear to work on simple single-disk systems, but will give inaccurate results on multi-disk systems even without snaps.
Perfect. I haven’t had time to revisit this issue but when I do, I will report back the results.