I am needing package an ASP.Net core webapp into a snap so I can run it on an ubuntu core device (A task I have learned to dread because its always a painful process). This application works well outside of snaps, I can even stop the snap sudo su into the path and run the binary and everything works but when it runs as a snap all the network communications get blocked and I get 404 errors. I have included the yaml below I have added all the obvious network plugs but to no avail.
The webapp is a vue3 front end
Communications are handled through signalR and largely is websocket based but the intial serve that is blocked is just a simple HTTP GET
Ok I have found the main cause to the issue to be the webapp was trying to load the from the var/… directory instead of its own container. Since there is only user data in this directory but not the app parts themselves this fails now why the system is pulling from the wrong directory I am not sure. This is fixable in my case by directly telling it where its own directory is but I am not sure why
returns the var path when historically it has always returned the snap path.
@ogra I appreciate you hoping in to help. Is the above behavior expected? if so I can consider this issue solved.
Daemon snaps have exactly two dirs they can write to, you should make sure your app uses these … both are exposed in the runtime environment via env variables …
SNAP_DATA → points to /var/snap/<snapname>/current, data in there will be bound to the currently running snap version and gets copied forward on refreshes (i.e. configuration and such should land there, the version binding makes sure rolling back your snap will get the user the exact config for this version (i.e., if config options or syntax change between to revisions, it will not break) …
SNAP_COMMON → points to /var/snap/<snapname>/common and should be used for bigger amounts of data that does not need to be versioned… i.e. caches, databases etc
I’d recommend to make your code use these two variables for your app so any writable bits can actually be written at runtime …
Yes currently that is how handle writable data, but the wwwroot file and binary are in the path provided by $SNAP env var. The ASP.NET webapplication builder uses by default the path returned by:
typically this path is the same as returned by $SNAP as this where the binary is running. In this case it it returns the path of $SNAP_DATA. there for the binary could run and knew where to write values and read configs ect. but it could not find the wwwroot file which for whatever reason does seem to throw an exception.
This is at least my working theory