Recently I became aware of the following eror message in the OH3 log:
2021-03-26 10:58:18.154 [ERROR] [org.apache.felix.fileinstall ] - Cannot create folder /Users/sven/Documents/openhab-3.1.0M2/userdata/tmp/bundles. Is the folder write-protected?
I moved my installation from my home folder towards system folder in order to run as a system daemon.
The new location is under /usr/local/opt/openhab. Also the user and permissions have changed.
Obviously, the moved OH3 instance tries to access its old location.
So I greped for config files pointing to the old location.
There are tons of *.cfg files referencing old location with absolute path information.
Furthermore, those entries are also found inside my backups generated via the backup-script.
I’m running OH3 on MacOSX.
It is an OH3 issue. I unzipped OH3 and started configuration in my home folder.
Later, I copied OH3 into a system location and run it as a system daemon.
But the OH3 daemon tries to access its old location, because there are absolute paths generated and pointing to the old/first location inside many config file of OH3.
So my questions remains: Is it possible to move an OH3 instance into a different folder on the disc?
When OH is started via start.sh or start.bat scripts, it is running under the current user.
On openhabian this is of course not the case.
However, the error itself is a permission error. This is correct.
But not because access rights are not correct. They are in fact.
Instead OH tries to access an incorrect folder, for which it intentionally has no access rights.
The OH3 daemon shall not access the home folder of my standard user, but it does.
This is caused by moving my OH instance from home to system locations.
I wasn’t running OH3 from the old location for a while.
A browser cache should not cause OH3 trying to access folders from previous location.
The browser should not know anything about the OH2 installation path.
I’m more concrned about thh config files.
Previous folder configuration is being foud in many *.cfg files.
I wiped the corresponding folders, but the issue itself remains.
To be clear, the issue is that OH3 tries to access some folders from its old location.
Knowldege about the old path/location must have been part of the bakcup I imported.
I used the standard backup and restore scripts.
So my questions why the backup contais absolute path information to its previsous installation?
Thank you for clarification. This is fine with me.
May I propose to provide this information with the script? It might be useful information also for others.
Additionally, may I ask for the feature to check whether a restore-location does not match the back-up-location? The restore script checks many issues before restoring the backup, but this one is missing.