You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
The company I am doing some work for at the moment is also interested in doing this. I have done some research and a small change that allows this to work but I came across some additional security issues.
But this flag only current works for NFS shares, and furthermore it has no effect if NO_NFS is defined in the code - which is defined for WIN_NT, FREEBSD, NETBSD, VMS
I am unsure if this RemoteFileOpenAbility change is on anybody's todo list at this point. (if not I would probably be capable of doing it)
If this change was to be done then it should inherently allow shadow files to be able to be placed on remote drives (and so would other types of files like DB files)
This change might have to be for embedded and super server only? Unsure if it would be safe for classic?
But there are some security problems under windows...
Since the fbserver processing is running as a service under the LocalSystem (SYSTEM) account it cannot make a connection through to the network share as it fails with username/password error. Changing the firebird service to run as a different user and giving that user r/w permissions for the remote share - and it all works nicely.
But I am thinking that a another possible solution would be to allow the username/password to be embedded into the share name e.g. user:password@\\server\share\shadowfile and the server can make the connection to the share using the provided credentials.
It has been many years since I have used nfs so unsure if it will suffer a similar problem (but I kind of doubt it)