Weird failure to mount after install of Sierra beta 8?

[ssh]

Are there any known issues with Sierra for Espionage? I can copy the password out and then mount the sparsebundle, but it won't mount from Sierra. It throws a red error, but no error message or other information. Just failure to mount. Recommendations?

[zsolt]

So what you are saying that if you copy the pass out and try to mount it on El Captain, then it works, but if you try to mount it in Sierra then it fails?
I suppose you use the same procedure, which one?
Can you unlock the folder using Espionage in Sierra?

Rgds
Zsolt

[ssh]

Sorry I wasn't clear...

1) Folder decrypts and mounts in El Cap using Espionage no problem.
2) Folder fails to mount in Sierra using Espionage
3) Copying the password out of Espionage and using Disk Utility allows me to mount in Sierra

Hope that clarifies?

[zsolt]

It does, I will check with devs

Thanks
Zsolt

[zsolt]

can you please try to  unlock it again in sierra using Espionage and monitor the console system log and all messages and see if there is anything related to the unlock attempt.

it seems that some testing on Sierra was done but we did not encounter any issues.

Thanks in advance for your input,

Zsolt

[ssh]

Hard to tell. Which processes are likely to be those I should search on? I'm getting a lot of log messages right now!

I'm not seeing anything that's jumping out to me, but I'm happy to look for anything you think could help. Any search criteria to limit the messages?

[zsolt]

just prepare everything, anchor the window of Espionage, then record the time stamp and click onto unlock, when the error message pops up, record the time stamp, then copy all the messages out of all messages and system in console, this operation lasts maybe 2-3 seconds so you should not get to many.
The espionage messages show up with espionage header, but I guess they do not come, otherwise you would see them.

Thanks
Zsolt

[zsolt]

Hello Jaldert,
​
​Here is a

https://www.espionageapp.com/other/builds/EspionageSierraBeta1.zip

​Would you be so kind to check if you can reproduce your problem with this beta build.
​
​Thanks in advance,

Zsolt

[zsolt]

Hello again, I just realised that the link is broken...and the devs are offline (it is night over there) so we will have to wait a few hours, I will let you know as soon as I get a new link.

Sorry about this

Zsolt

[greg]

Link is fixed now, sorry that was my fault!

[zsolt]

And hello again and again....the other user we sent the beta to, reported that it did not help. However, we figured out that he is trying to unlock a folder which resides on an external disk. If this is true in your case too then please try the following:

​Can you please create an empty folder on your internal disk, in your Documents folder for example, then unlock espionage, click onto small "i" near the folder name, and in the folder options window use the mount point folder drop down menu to point Espionage to the newly created folder.
​Once you switched the mount point folder to the new one, try to unlock the folder again, let me know how it went
​
​Thanks
Zsolt

[tobysmurf]

I just ran into this issue with the formal release of Sierra.  Mounting to a local disk as opposed to my SD card does work.  Any suggestions on how to fix the issue with mounting to an external disk?

[zsolt]

We can reproduce the problem using Apple's hdiutil which we use for mounting, so it seems to be Apple's bug, we are currently investigating if we can circumvent this, but at the moment the only workaround we can offer is to move the mountpoint folder to a local disk. It is not a big deal though as the data is still on the external disk, but it requires a bit of manual work which is not what we want.

We will update as soon as we find some better way.

Rgds
Zsolt

[ssh]

Thank you. My travel schedule has kept me away from this issue for a while. I will attempt the local mount point, but sounds like that fixes it for now.

[zsolt]

Dear All,

So here is the final verdict on Sierra and failing folder opening:
Espionage uses encrypted sparse bundle disk images which are a data format provided by Apple's OS X. It is a clever and flexible approach of storing data safely. This is why we went that route and it worked fine for many years.
Apple also provides a command line utility to manage and manipulate those disk images, this utility is called hdiutil.

After troubleshooting the problem, it turned out that if we specify to the hdiutil a mountpoint folder path which is located on an external volume, then the hdiutil returns a "no mountable filesystem found" error in spite of all data being in good condition. It is sufficient to specify a mountpoint folder which is on the system disk and all starts to work fine.

The problem being in Apple's utility, we cannot do much more then report it to Apple. At which priority will Apple address this problem, we have no clue.

Till then there are two workarounds:
1. move the mountpoint to the system disk, as we suggested earlier
2. do the 1. but create a so called symlink on the external disk where the original mountpoint folder was located. This symlink is very similar to Alias of a folder in Finder, it is a folder which "points" to another folder. In this way you could access the content of the protected folder in a same way as before, although there would be two mountpoint folders, one real, on your system disk and one which would look as real, but would in fact be a link to the one on the internal disk. If you want me to send instructions how to create the symlink, let me know.

Thanks for your patience in this matter,

Rgds
Zsolt