This one is from the Apache error log (/var/log/httpd/error_log) and is generated whenever an attempt to connect to the resource via the web interface is made:

[error] [client 127.0.0.1] Could not open the requested SVN filesystem  [500, #2]

This is what was visible from the web browser.  This is its rendering of the XML response.

<D:error>
<C:error/>
<m:human-readable errcode=”2″>
Could not open the requested SVN filesystem
</m:human-readable>
</D:error>

This one arose when attempting to run the svn command as the apache user (sudo -u apache svn list….)

svn: Can’t open file ‘/root/.subversion/servers’: Permission denied

I eventually discovered that this problem was being caused by the Subversion binary looking to the root home directory, instead of to the Apache / httpd home directory (~apache which was /var/www in my configuration.)  This is not the correct behaviour but until the issue is fixed you can fix the problem yourself with this:

cp -r /root/.subversion/* ~apache/.subversion/

chown -R apache:apache ~apache/.subversion/

automount[10581]: >> mount: block device 192.168.0.2:/data/home/samiller is write-protected, mounting read-only
kernel: call_verify: server 192.168.0.2 requires stronger authentication.

It turns out that the solution is quite simple. The issue is with a mismatch of anonymous credentials. Let’s take a look at the erroneous entry in /etc/dfs/dfstab on the Solaris NFS server:

share -F nfs -o public,nosuid,rw,anon=-1 -d "backup" /data

The piece of this configuration that is an issue here is “anon=-1”. In theory this is designed to block users who do not have accounts on the local system. However this causes issues with Linux systems. You can solve this problem by simply removing the anon setting from the configuration file. Not an ideal fix but it does solve the problem.

share -F nfs -o public,nosuid,rw -d "backup" /data

Simply run the “shareall” command and you should be back in business.