No suitable backend was found for /Volumes/Secure/GnuCash2016/Personal2016.gnucash

Eric Beversluis ebever at researchintegration.org
Thu Sep 28 14:17:31 EDT 2017



Eric Beversluis  
Short fiction at www.ericbeversluis.com

On September 28, 2017 at 12:56:30, Eric Beversluis (ebever at researchintegration.org) wrote:
>  
> Eric Beversluis
> Short fiction at www.ericbeversluis.com
>  
> On September 28, 2017 at 12:17:20, John Ralls (jralls at ceridwen.us) wrote:
> >
> > > On Sep 28, 2017, at 8:58 AM, Eric Beversluis wrote:
> > >
> > > I’ve recently moved to Mac Sierra. Have been using GnuCash successfully there. This  
> > morning when I opened gnucash I got this message:
> > >
> > > No suitable backend was found for /Volumes/Secure/GnuCash2016/Personal2016.gnucash  
> > >
> > > ??
> > >
> > > Only thing I can think is that I moved some older versions of my GnuCash files to trash.  
> > Had several sitting in other places as a result of the move and of setting up the encrypted  
> > image /Volumes/Secure.
> > >
> > > I seem to be able to open one of the backups, Personal2016.gnucash.20170927131325.gnucash.  
> > But when I try to save it as Personal2016.gnucash, after having moved the original Personal2016.gnucash  
> > to trash, I get the same “No suitable backend” error.
> > >
> > > Also strange: Mac or GnuCash or something is creating these two zero byte files:
> > >
> > > Personal2016.gnucash.20170927131325.gnucash.0.1139.LNK
> > > Personal2016.gnucash.20170927131325.gnucash.LCK
> > > ??
> >
> > Those files are created by the xml backend. The LCK file is the lock file that the backend  
> > uses to ensure that only one user is connected to the file at a time. The LNK file is part  
> > of a hack to ensure that locking works on an old remote file protocol called NFS, for "network  
> > file system".
> >
> > If you save Personal2016.gnucash to a non-encrypted volume is GnuCash able to open  
> it?
> > Does enabling or disabling compression in Preferences (General tab, middle of the  
> page,
> > "Compress Files") make a difference?
> >
> > Is /Volumes/Secure encrypted with File Vault or a third-party program?
> >
> > Regards,
> > John Ralls
> >
> >
> If I save the backup to Desktop as Personal2016.gnucash, it opens.
>  
> If I ‘save as’ the open version to /Volumes/Secure/GnuCash2016/, it get the error. Even  
> after disabling compression before the save as.
>  
> I tried saving to /Volumes/Secure/Gnucash2016/ as Gnucash2016_New.gnucash, but  
> that generated the same error on opening.
>  
> If I try to copy the GnuCash2016_New.gnucash version to Desktop I get this error:
>  
> "The Finder can’t complete the operation because some data in “GnuCash2016_New.gnucash”  
> can’t be read or written.
> (Error code -36)”
>  
> But despite this warning, it copies something there with a size of 3.3MB, whereas the  
> other files are all aboutl 254KB.
>  
> The wierd thing is that it seemed to be working OK until I moved the non-secure copies to  
> Trash.
>  
> The secure partition (image?—not fully up on Mac jargon yet) was created with Disk Utility  
> > New Image > Blank Image. Whether that uses File Vault I don’t know. I somehow thought  
> File Vault encrypted the whole disk.

Thought maybe it was a permissions thing. Changed to 755 and used terminal to copy to /Volumes/Secure. Looked like that solved it.

But no. What’s happening: even if I click on the file in the secure directory, GnuCash is opening the one on the desktop. 

If I rename the one on the Desktop and try to open the one from the secure directory I get the old “No suitable backend” error. I think this has been happening all along and moving the non-secure versions to trash made that no longer possible.

That’s weird: click on one file and gnucash chooses to open a different one.


More information about the gnucash-user mailing list