iLEAPP fails if output dir is on a network share - sqlite3.OperationalError: database is locked

[jarlethorsen]

When setting the output directory to a network share (and using an archive as input) I get a lot of errors like this:

Safari Browser [safariHistory] artifact executing Reading Safari Browser artifact had errors! Error was database is locked Exception Traceback: Traceback (most recent call last): File "/home/user/Sources/iLEAPP/scripts/ilap_artifacts.py", line 359, in process_artifact method(files_found, report_folder, seeker) File "/home/user/Sources/iLEAPP/scripts/artifacts/safariHistory.py", line 58, in get_safariHistory timeline(report_folder, tlactivity, data_list) File "/home/user/Sources/iLEAPP/scripts/ilapfuncs.py", line 134, in timeline cursor.execute('''PRAGMA journal_mode = WAL''') sqlite3.OperationalError: database is locked

Sqlite has a known issue with database locking when the database is located on a network share (I have also seen this in my own projects)

Maybe you can catch the "sqlite3.OperationalError: database is locked" exception and inform the user that this may be a result of having output path on a network share,

or

use tempfile.TemporaryDirectory() to create the temporary directory. (It even comes with a context-manager that takes care of cleaning up afterwards). This way the temp dir will be created in the default system location for the user, but the result may still be created wherever the user chooses?

[ydkhatri]

Can you provide more details? Is the input a folder/zip/tar? Is the output also on a network drive? Are you accessing via drive letter or //server/folder path? Is your network drive read-only?

[jarlethorsen]

The problem here is related to running cursor.execute() on a sqlite3 database that happens be located on a network share.

A google search turns up a dozen similar issues in other projects, related to storing the database on a network share, like this one: https://stackoverflow.com/questions/57248340/how-do-i-unlock-a-database

In the case of iLEAPP this is directly related to where the temporary directory is created.

If the input is a folder or gz does not make any difference, (this makes sense, as I would imagine you copy the db to the temp-dir before you open it, no matter the type of input, to avoid making changes to the original db?)

Personally I'm using iLEAPP on a linux system where the network shares are mounted cifs shares. (None of the network shares are read only).

For example I can process '**/Safari/History.db' just fine, no matter if the source is a folder or a gz, or the source is on a network share or local disk, the only thing that will make it fail is setting the output to anywhere on a network share.

I'm not saying that I'm 100% sure that the problem can't be solved my changing some samba mount options on my end, but I would still argue that using tempfile.TemporaryDirectory() would be the better (cross-platform) route to take.

[ydkhatri]

In general, the project could use a lot more exception handling. I'm going to study this a bit more to try to reproduce and see what the most optimum solution might be.