An Autopsy snap package file can be installed by running sudo snap install --dangerous autopsy.snap. The --dangerous needs to be specified because the snap package isn't signed (see install modes for more information). By default, snap doesn't allow certain interactions with the operating system. These Super-privileged connections may need to be connected. This can be done manually by running snap connections autopsy to determine any missing connections, and then running snap connect autopsy:home replacing home with the name of the plug. Another option is to run this script, which will connect all missing plugs: snap connections autopsy | sed -nE 's/^[^ ]* *([^ ]*) *- *- *$/\1/p' | xargs -I{} sudo snap connect {}. One other possible option may be to install the application with --devmode instead of --dangerous. The --devmode flag is more permissive and will allow all connections to the operating system. More information on interface management can be found at the snapcraft website.
After installing Autopsy, you should be able to run with autopsy. Snap also typically installs a .desktop file for your launcher. If you want to perform an ingest on a local disk, you will need to run with permissions for disks in the /dev folder. On Ubuntu, that command will be sudo -g disk autopsy as disk group permissions will give access to that folder.
A snap package of Autopsy can be generated using the snapcraft.yml file. You will need snapcraft on your system and lxd works well for virtualization while building the snap package. Since snapcraft needs virtualization to create the snap package, your computer's hardware will need to support virtualization and any relevant settings will need to be enabled. From testing as of November 2022, VirtualBox and WSL are not good build environments. Once the development environment has been set up, a snap package can be built with this command: snapcraft --use-lxd --debug run from this directory. If you want to build async, but still get logs, you can run something like this: nohup snapcraft --use-lxd --debug > ./output.log 2>&1 < /dev/null &.
The version of Autopsy in the snapcraft.yml can be updated by calling version_update.py with a command like python version_update.py -s sleuthkit_release_tag -a autopsy_release_tag -v snapcraft_version_name. You will likely need to install the python dependencies in the requirements.txt with a command like: pip install -r requirements.txt.
The version of Autopsy can be updated manually by modifying fields relating to git repositories and commits in snapcraft.yml under parts.autopsy and parts.sleuthkit. Specifically source, source-branch, and source-tag. More information can be found here.
An error like "Local Solr Server did not respond to status request" or something similar, may indicate that not all snap connections may have been connected. By default, snap doesn't allow certain interactions with the operating system. These Super-privileged connections may need to be connected. This can be done manually by running snap connections autopsy to determine any missing connections, and then running snap connect autopsy:home replacing home with the name of the plug. Another option is to run this script, which will connect all missing plugs: snap connections autopsy | sed -nE 's/^[^ ]* *([^ ]*) *- *- *$/\1/p' | xargs -I{} sudo snap connect {}. One other possible option may be to install the application with --devmode instead of --dangerous. The --devmode flag is more permissive and will allow all connections to the operating system. More information on interface management can be found at the snapcraft website.
Autopsy looks at the block devices in the /dev directory for local disks to process. If autopsy can't read block devices in that directory, it won't show the local disk. In most instances, starting autopsy with a command like sudo -g disk autopsy should give autopsy the right permissions to view local disks. This assumes that the disk group has read rights to local disks (i.e. /dev/sda1). Appropriate permissions can be determined by running something like ls -l /dev looking for the permissions required for the local disks. Then autopsy should be started in such a way that the $USER and $HOME are preserved (i.e. running as root may be problematic), but the user account and, consequently, autopsy, has sufficient permissions to access local disk block devices.