[mythtv-users] NFS mounts permissions

[Matt Mossholder]

On Sat, 2007-09-08 at 12:41 -0400, Daniel Kristjansson wrote:
> On Sun, 2007-09-09 at 01:53 +1000, Bruce Nordstrand wrote:
> > I have just completed a rebuild of my combined backend/frontend into a 
> > master backend only (3 cards), 1 slave backend (1 card) and 1 frontend 
> > only. I seem to have an issue with the permissions on my NFS mounts on 
> > the slave backend.
> > 
> > This is my define in /etc/exports for the myth recordings directory on 
> > the master backend:
> > 
> > /myth-data 10.0.0.1/24(rw,no_root_squash,async)
> > 
> > The recordings are actually in a sub directory, recordings.
> > 
> > I created a mount point on the slave, /myth-data and mounted the NFS 
> > directory on that. The permissions on the slave directory were set to 
> > mythtv:mythtv and 775. However, the slave is telling me it has no 
> > permission to write to the recordings directory.
> > 
> > What am I doing wrong?
> 
[snip]
> If they don't agree you can't authenticate. Also if you run the
> backend as root you generally can't write to NFS shares because
> most NFS implementations only give the root account guest access
> if they give it any access at all.
> 
[snip]
> 
> -- Daniel

Bruce has already handled the UID 0 issues by specifying
"no_root_squash" in the /etc/exports line he mentioned above. 

I agree that the issue is probably a UID mismatch between the systems.
Not sure that I agree that using yp,ldap or anything else would be such
a hot idea, though. 

On most distros, mythtv is a system account, and is expected to have a
UID below 1000. Things tend  to get funky when you put system accounts
in remote user stores. For example, useradd won't add it to the remote
store, which may break installing the package. 

You also may miss recordings if your password server is down (check into
pam-ccreds and libnss-db to work around this).

It can definitely be done, just expect some jiggerying to get it working
right :) Personally, I do it, using OpenLDAP for storing user accounts,
Heimdal (stored in LDAP) for authentication, and ensure it keeps working
with pam-ccreds and libnss-db (to allow caching of the account and
password info in cause the LDAP or Heimdal server is down).


		--Matt