Here is the use case: a LAN drive, call it J:, is shared among eight or so users in an office.
Joplin Portable and the profile folder lives on J: and each user has a shortcut to the executable on their desktop. Thus the executable will run on multiple PCs, each accessing the single office profile.
The advantages of this setup are many; security is automatically based on access to the J: drive, program updates are done in a single location, and the drive is being backed up regularly by the IT department.
It’s mostly used as a documentation resource; it’s very rare that multiple people would be editing at the same time and I doubt any two people would ever edit the same page.
It’s been working well up until 3.4.x, but now it’s having issues starting the application.
We’re seeing some errors in the logs related to a Node.js “feature” that checks a IPv6 address before falling back to IPv4, and there may also be an issue with the PC trying (and failing) to run the 32-bit version on unpacking, rather than the 64-bit.
Or it may be related to the number of users who have the executable running in the background.
Another possibility is that the profile is locked or corrupted somehow, though if I copy the profile and executable to the C: drive it seems to work.
Thoughts? Are there any technical concerns with this setup? If so, are there any workarounds?
Is your reason for all sharing the same profile folder for all Joplin instances, in order to avoid needing to transmit data over the internet? To be honest that setup seems like asking for trouble. Even if not everyone edits at the same time, I foresee locking issues if multiple Joplin instances are just running at the same time, all pointing to the same local profile.
An alternative option which does not expose the data to the internet, would be to create a WebDAV server only accessible on the LAN, which all Joplin instance would use as the sync target. They would share the same sync target, but the local profile data can be kept separate for each instance.
Alternatively if you don’t want to run a server but stick to just the network drive, you can setup all clients to use file system sync, to sync to a directory on the network drive. You’ll want to download the Joplin 3.5 prerelease if doing that though, as it has a fix for a longstanding issue with file system sync
There is only one store of information, so it seems logical to have a single profile pointing to a single database. SQLite seems to have fairly robust locking functionality; I don’t know if Joplin leverages that or not, or if Joplin has its own concurrency management (or has ever thought it necessary as this is an unusual use case I think).
As I mentioned, it’s been working well for several years, we’re just starting to see some issues when too many people are running their copy of the executable at one time. Your last idea is intriguing…
Regardless of whether your method was working in the past, it’s not recommended by the developers. Using one of the methods I mentioned would be the official way to manage this, and it would also support concurrent editing using the conflict detection mechanism (but the conflict resolution needs to be done manually)
Also SQLite databases don't work properly on LAN drives or cloud folders, like OneDrive or Dropbox because they can update the files in any given order and so the SQLite journal might end up out of sync with the database, which will cause data corruption.
I can see how your setup would be convenient but it's not recommended. Mrjo118's suggestions would definitely be the way to go.