Did you try install GlassWire on another computers? Did it has same problem?
I tried it in a Virtual Machine, and it didnât have the problem. However, that unfortunately doesnât deal with the fact that no matter what I do on my actual PC, I canât backup the file. Since the file created by Glasswire on another PC was copyable, I attempted to copy it to the Glasswire.db location on my current PC; that file was copyable as it should be, but then the glasswire service wouldnât start. I also tried creating an initial blank Glasswire.db file (i.e. an empty file) on my PC, which is copyable, but again, the Glasswire service wouldnât start - unless I delete it and let the service create its own initial file, which is never copyable. So no matter what I do on my PC, the Glasswire service creates a database file for itself that has this problem.
I talked about this forum thread with the development team. GlassWire is still in beta and we didnât plan to make it possible or easy for users to move the GlassWire database around.
However we are thinking about adding an âexportâ feature so users can export their database if they want to but we want to make sure itâs done in a safe secure way. If we made an export feature in the future would that solve the problem?
Also weâre not sure why your computer has this problem with our current beta and we canât recreate it on our end but we didnât intend for users to move the GlassWire database around at this stage so weâre not sure what to recommend. Sorry for the problem and I apologize for any confusion.
Hopefully we can get the export feature done soon for you.
Export would not do it.
Every single program, service, etc on my system has been configured to store its relevant database/config/user information on one partition on my SSD; this includes web browser profiles, iTunes database, Outlook PST, VMs, Skype profiles, Lightroom catalog, Evernote database, Quicken, XAMPP, SVN repos - literally everything that stores personal info/data and changes on a regular basis. I could reformat my system partition at any moment and not lose a thing. One of the main reasons for keeping all of this config in one place is for the sake of an automatic backup, which mirrors that partition to a remote network drive. As it stands, Glasswire is the only - and I do mean only - thing that this backup is unable to copy. An âexportâ feature wouldnât remedy this; it would make it the only thing (among dozens) requiring me to do a manual export prior the backup running.
This whole issue is simply about having an automated backup such that if my system gets lost, stolen, dropped, or in any way damaged, I can be back up and running exactly where I left off in a couple hours. Itâs about being able to mirror Glasswireâs database, from where itâs used, to another location. Simple.
Aha, now I get it. Sorry I misunderstood. So I think weâd need to have some kind of âdatabase locationâ setting where you can choose to move the GlassWire database wherever you want. For example if I wanted to put it in Dropbox I could do so. Right?
While Iâm sure a setting would be handy, this is already doable via db_file_path in C:\ProgramData\GlassWire\service\glasswire.conf. The sole problem for me is that no matter what I do, the glasswire.db file created by the glasswire service on my PC cannot be copied/accessed. If I move it to the dropbox folder, dropbox canât access it; I canât copy it in Windows, in dos, in safe mode, my backup process canât copy it, etc - as described above & shown in the screen captures.
Itâs really odd that it doesnât do this on other systems, but I donât know what else to say: no matter what I try, if glasswire is allowed to create glasswire.db, then that file cannot be copied/read. If I try to take a glasswire.db that was created on another PC (which can be copied/read) and use it as a âstarting fileâ on this PC, the service wonât start (and doesnât seem to display any error or anything). So I simply cannot backup the file. Only rename/delete it.
âŚOmg, after all these hours I just this minute figured it out!! Not a solution, but the cause - which should hopefully let you communicate it to the developers for a fix.
The issue occurs only when glasswire.db is stored within an encrypted folder (aka Windows 7 EFS).
->If the folder that will contain glasswire.db is not encrypted & I start the service, it will create glasswire.db (not encrypted) that can be copied/accessed.
->If the folder is encrypted, it will create glasswire.db (encrypted) which glasswire itself can use just fine, but nothing else can copy/backup
->If the folder is not encrypted and I let glasswire create a non-encrypted db, but then I encrypt it, then the glasswire service wonât start.
So it seems to be doing something different when the db is encrypted vs not, which it shoudlnât - EFS is supposed to be transparent. If it creates an un-encrypted db it can be used, but never encrypted; if it creates an encrypted DB, it can be used but never copied. For obvious reasons, the partition described above - which contains all my personal and private data - is encrypted. So that seems to be the problemâŚ
1 Like
So again, just to summarize the issue in one sentence:
If I encrypt glasswire.db, either the Glasswire service wonât start (if it was first created as non-encrypted and then encrypted later), or glasswire.db canât be backed up (if I allow Glasswire to create it initially encrypted, i.e. in an encrypted folder).
Now I understand why you have a problem.
https://en.wikipedia.org/wiki/Encrypting_File_System:
The FEK (the symmetric key that is used to encrypt the file) is then
encrypted with a public key that is associated with the user who encrypted the file, and this
encrypted FEK is stored in the $EFS alternate data stream of the
encrypted file.
So problem is, since every user has itâs own key - other users could not access content of such files in any way, just since it cannot be decrypted. SYSTEM has itâs own key, your user has itâs own⌠Thatâs itâŚ
There are following ways to solve problem:
- do backup under account which glasswire service runs (and you could try run service from other than SYSTEM account);
- run glassware service under account which do backup;
Thatâs it. At long, long, LONG last, problem: solved!
Step 1: Use psexec (http://technet.microsoft.com/en-us/sysinternals/bb897553) to start a command prompt as the local system account
Step 2: Use cipher.exe to decrypt the encrypted glasswire.db account glasswire had created
Step 3: Re-encrypt glasswire.db from windows explorer (from my own user account)
Step 4: Services.msc->Glasswire Control Service->Logon tab, tell it to logon as my user account
âŚAnd everything works. Glasswire.db is encrypted, readable by the Glasswire service, and readable by myself (and the backup software, which runs under my user account).
Phew! 
5 Likes
Iâm glad the mystery is finally solved! Thanks for reporting this so other users can read about this problem and solve it.
Thanks so much for solving this! Still, accessing the DB like this is far from convenient.
For everyone who needs this workaround now, It may become mostly unnecessary if this feature request gets implemented in the future:
Search Function & Log Viewing
(Sorry. Iâm new so I canât post the link, but search brings it up)
Fortunately, @Ken_GlassWire replied that "A search function is on our list of things to do. 
"
I thought people on this thread would like to know an actual solutionâs on the way, and in case you want to hit the 
button on the request⌠Itâs clear that the devs are listening.
I believe that Ken has moved on⌠have not seen any posts from him here since early this year.
The helpdesk has responded to some posts in the Glasswire Help category.