Try the following:

<pre>
export HOME=/
cd /tmp
fossil new test.fossil
</pre>

The following message is produced:

<pre>
fossil: SQLITE_CANTOPEN: cannot open file at source line 26294
fossil: unable to open database file

If you have recently updated your fossil executable, you might
need to run "fossil all rebuild" to bring the repository
schemas up to date.
</pre>

This example assumes that the logged in user does not have write access to / but does have write access to /tmp.
This is a contrived example that demonstrates the problem; the actual problem was encountered while attempting to use fossil when running as another user (via sudo), but with the old value of HOME (the default sudo behavior of preserving the original environment).

If instead HOME points to another user's directory that has a .fossil, but the current user does not have write access to it and you attempt to clone (instead of just new) you get:

<pre>
fossil: SQLITE_READONLY: statement aborts at 19: [INSERT OR IGNORE INTO global_config(name,value)VALUES('repo:/tmp/foo.fos',1)] attempt to write a readonly database
fossil: attempt to write a readonly database
INSERT OR IGNORE INTO global_config(name,value)VALUES('repo:/tmp/foo.fos',1)

If you have recently updated your fossil executable, you might
need to run "fossil all rebuild" to bring the repository
schemas up to date.
fossil: SQLITE_ERROR: statement aborts at 2: [ROLLBACK] cannot rollback - no transaction is active
</pre>

I was expecting fossil to work whether or not it can muck around with ~/.fossil.  vim works whether or not it can write to ~/.viminfo (although it does complain if it can't).

fossil breaks if HOME points to read-only directory