Write Permissions With Remote NFS Shares
For the past several weeks I have been testing Slackware 14.2 as I prepare to update all systems from 14.1 systems.
Currently I have a mixed environment. I have my office desktop and laptop dual booting between 14.1 and 14.2. Mostly though I am using 14.2 on both systems. The office desktop and laptop are my proving grounds. All other systems, including the server, are on 14.1. The server will be last of the home computers to update to 14.2.
I have found more than a few bumps in the transition from 14.1 to 14.2, which has not been a smooth ride. A recent bump confused me for more than day.
I have two TV tuner cards, each in a different computer. Each tuner card only supports one input signal. One tuner card is in the server and the other is in the office desktop. Most of the recordings occur on the server. I use the office desktop tuner card when two recordings have overlapping time periods.
I designed the recordings from the office desktop to be stored on the server. I use NFS to create the shares. I use the living room media streamer to watch the recordings from the server.
Until recently I never had a problem recording from the office desktop to the server. I noticed the office desktop was not recording to the NFS share on the server. Instead the recording was reverting to a local directory. I designed this fallback option long ago should anything happen to the server. Always have a Plan B.
I never had a problem with concurrent recordings between the two systems. The office desktop has many times recorded to the server. Now this was broken.
Plan B was being used. Why? What happened recently to cause this new behavior?
The cause of the problem was insufficient write permissions to the server. The recording script performs a simple write test to verify permissions. The write test was failing. Yet this was working fine only a few weeks ago.
The problem never existed until I started testing 14.2. Was the problem with 14.2 or did I do something that created that illusion? I have been merging differences between 14.1 and 14.2 to smooth the transition. While I have been methodical about the merges, I could have made a mistake. Or encountered some new element previously unknown to me or my expectations.
The inability to record to the server was a big clue but not my first clue. With some hindsight I realized I have been seeing this problem for a while.
I use a script that allows me to test the next scheduled recording. I do not use cable or satellite. I receive TV signals over-the-air (OTA). Once in a while I have to bump the TV antenna to ensure a good signal. The script helps me watch that.
My recording script expects to store recordings to the server. The fallback plan stores recordings locally. I had ran my test script and later noticed the appearance of this local directory, which never existed before. I should have investigated but did not. The primary account used on the office desktop is a member of my htpc group, which is required to save files on the server to the recordings directory. Clue number 1.
My primary user account on my laptop was unable to save files to my build directory. The account I use on the laptop is a member of my compilers group. I should have been able to save files to that directory. Clue number 2.
I was reasonably certain the cause of both problems was the same.
After some digging and testing I got the feeling the server was ignoring group IDs (GID) and only honoring user IDs (UID). This was a decent feeling. By focusing my online search with respect to “ignoring GID,” I soon stumbled upon discussions about an ancient and stupid 16 group limitation of NFS.
The accounts I use on the office desktop and laptop are members of more than 16 groups.
The solution is simple. When executing rpc.mountd on the NFS server, use the --manage-gids option to overcome the 16 group limitation.
The option makes sense with what I saw in my testing. The NFS server was ignoring GIDs.
I added the option to the Slackware rc.nfsd script and restarted the NFS server.
I then could save files to the server from the office desktop.
Likewise from the laptop.
Unresolved is why did this problem only recently occur? I had no problems with the recordings until recently. What changed?
I am using NFS 3. The Slackware nfs-utils package is not compiled with NFS 4 support. Thus NFS in Slackware depends upon matching UIDs and GIDs between the client and server. This was not the problem in my use case. I keep the /etc/passwd and /etc/group files synced among all Slackware systems. Thus UIDs and GIDs are always the same.
The root cause was my merging of files as I move toward updating to 14.2. I checked the /etc/group in my backups from before I started tinkering with 14.2. Sure enough, both user accounts were then members of 16 groups.
In my effort to move toward 14.2, I backported the new groups of 14.2 to the 14.1 /etc/group file. This allowed me to keep the file synced between the 14.1 and 14.2 systems during my transition. I added my two respective primary user accounts to the new groups. Each user became members of the pulse and polkitd groups. The additions pushed both accounts past the 16 group limit to 18.
I have no memory why I incorrectly added the two primary users to those groups. After resolving the original write permissions problem I removed the two users from those two new groups. That brought both users back to within the 16 group limit.
I am leaving the rpc.mountd change as is. No need to run into that silly 16 group limitation ever again.
Posted: Category: Usability Tagged: General, Slackware
Next: A New Forward Button
Previous: Simple SSH Intrustion Detection