I have a snap that packages a java web application, complete with logging, caches and an OSGi container.
All is working well, I’ve managed to externalise the resource locations for the database and log configuration so that it is configurable post installation.
However, we have a folder that contains the theme for the application and this lives in the web root folder.
What I need to do is sym link this to a folder in $SNAP_USER_COMMON during installation i.e. sym link $SNAP/themes to $SNAP_USER_COMMON/themes.
I tried this in an install hook but it fails of course because the file system is read-only at this stage.
Is there anyway that the snap can make this happen i.e. make changes to the new file system before it becomes read-only?
It will be a big task to change our application to make this folder dynamic so anything I can do here would be a life saver.
A snap’s filesystem doesn’t “become read-only”, it is always read-only. You cannot modify a snap once it is packaged and uploaded to the store because it is a squashfs filesystem that is signed cryptographically. Squashfs filesystems cannot be modified directly, but can be recreated, however the cryptographic signatures cannot be recreated outside of the store and especially not on an end-user device as they install the snap.
There are two ways you can attempt to solve this problem:
Use layouts which is behind a feature flag awaiting stabilisation in snapd.
Point a symlink at $SNAP_COMMON or $SNAP_DATA instead of the _USER_ variants.
Regarding 2. the $SNAP_USER_COMMON and $SNAP_USER_DATA are only available when a user has decided to launch your application directly. If your application is supposed to always run then you will need to use $SNAP_COMMON or $SNAP_DATA anyway because the application won’t be running within a user context. It is the running without user context that also prevents you accessing $SNAP_USER_* from a hook script on installation.
Many thanks for your replies and the clarification of the packaging structure.
The reason we have bee using $SNAP_USER_COMMON is because we want the data to persist just in case the user completely uninstalls the product.
I don’t think it is possible to create a sym link in the yaml because the $SNAP_COMMON/$SNAP_DATA variables are not known during build and sym links can’t evaluate variables except during the creation.
