Phil Stracchino schrieb am 10.05.23 um 20:11:
On 5/10/23 11:19, Chris Wilkinson wrote:
This is not really a Bacula question but I'm hoping someone has come
across this when using NFS to mount a NAS storage device.
As I understand it, the UID:GID on the remote storage and the local
SD daemon must match or permission denied results. My NAS has NFS v3
and this can't be changed.
I can create a new user on the NAS but I have no control over what
UID:GID it chooses and will not be the same as the SD daemon user:group.
I believe NFS v3 doesn't have the capability to map UIDs; that
facility is v4 only.
Has anyone found a workaround for this?
What is the NAS? I'm guessing if you don't have the ability to
control UIDs/GIDs on the NAS you probably can't install a SD on it
directly either. NFS-mounting your Bacula backup storage is usually a
bad idea unless you have no alternative.
Honestly, in my experience off-the-shelf consumer/prosumer NAS
appliances are utterly horrible from a management perspective — you
WILL do things THEIR way, or not at all. I tried a consumer NAS a few
uears ago — I'm blanking on the brand right now — and had to return it
because not only was it useless for what I wanted, as well as having
some pretty ghastly security issues. (Like making every file on every
share world-read/write via NFS.)
If you can't control the UID/GID assigned by the NAS, can you change
the UID/GID of your storage daemon to match what the NAS assigns?
That would at least solve the permission problems.
For a typical user NAS (which it seems to be and not a professional one)
that is not unusual. I strongly recommend to use CIFS instead. This will
not make it possible to change the UID/GID on the NAS side, but locally
you can mount them as needed. If the NAS does not offer user management,
you are pretty much stuck here.
cheers
TB
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
