I am having difficulty with NFS permissions on my SNAP server, specifically inherited permissions. I'll try to "write" you a picture...
SNAP Server Details
SNAP 4500 with 4 250G Drives, RAID 5 (VOL0)
SNAP 10 expansion array with the same drive configuration (VOL2)
VOL0 is setup with "Windows" shares and permissioning works fine. This is my corporate "share" drive.
VOL2 is setup with "UNIX" permissioning and is my problem child.
The purpose of VOL2 is to be a repository for my Linux server backups. There is one share created as a mount point, "backup", set with AllUsers RW permissions. I created sub-directories under the BACKUP folder [share] for each of the servers. Permissions on each of these folders is 777. Here's how it's setup:
SNAP Server: SNAP
Backup server: BACKUP
Server to backup: SERVER1
From BACKUP I mount the SNAP server: mount -t nfs SNAP:/backup/server1 /mnt/snap/server1
From BACKUP I mount the server to be backed up: mount -t nfs SERVER1:/ /mnt/server1
Now I run a backup app (rdiff-backup) from /mnt/server1/<backup dirs> to /mnt/snap/server1
***The "picture" above is probably a little muddled but may provide a little insight as to what I'm doing. Just use it as a reference point***
All mounts work fine and all file systems are visible and available. When RDIFF-BACKUP runs it attempts to begin creating folders (/mnt/snap/server1/<folders being backed up>. It dies here.
If I manually create a folder or file the permissions are automatically set to rw-r--r--. The GuardianOS (SNAP OS) uses most restrictive permissioning so the group has read only and it kills the write there.
You have to be familiar with the SNAP server to understand what's happening here. Does anyone know how to change the [unix] inheritance permissions for folders/files created under the "share"? Incidentally, when you mount the server items created are owned by 65534:65534 (nfsnobody).
Any help would be great.
Tony
SNAP Server Details
SNAP 4500 with 4 250G Drives, RAID 5 (VOL0)
SNAP 10 expansion array with the same drive configuration (VOL2)
VOL0 is setup with "Windows" shares and permissioning works fine. This is my corporate "share" drive.
VOL2 is setup with "UNIX" permissioning and is my problem child.
The purpose of VOL2 is to be a repository for my Linux server backups. There is one share created as a mount point, "backup", set with AllUsers RW permissions. I created sub-directories under the BACKUP folder [share] for each of the servers. Permissions on each of these folders is 777. Here's how it's setup:
SNAP Server: SNAP
Backup server: BACKUP
Server to backup: SERVER1
From BACKUP I mount the SNAP server: mount -t nfs SNAP:/backup/server1 /mnt/snap/server1
From BACKUP I mount the server to be backed up: mount -t nfs SERVER1:/ /mnt/server1
Now I run a backup app (rdiff-backup) from /mnt/server1/<backup dirs> to /mnt/snap/server1
***The "picture" above is probably a little muddled but may provide a little insight as to what I'm doing. Just use it as a reference point***
All mounts work fine and all file systems are visible and available. When RDIFF-BACKUP runs it attempts to begin creating folders (/mnt/snap/server1/<folders being backed up>. It dies here.
If I manually create a folder or file the permissions are automatically set to rw-r--r--. The GuardianOS (SNAP OS) uses most restrictive permissioning so the group has read only and it kills the write there.
You have to be familiar with the SNAP server to understand what's happening here. Does anyone know how to change the [unix] inheritance permissions for folders/files created under the "share"? Incidentally, when you mount the server items created are owned by 65534:65534 (nfsnobody).
Any help would be great.
Tony
