Merge branch 'docs/2.4' of github.com:vsoch/singularityware.github.io into docs/2.4

Author: vsoch

pages/docs/admin-docs/advanced-config.md

@@ -48,6 +48,11 @@ In addition to the system bind points as specified within this configuration fil
 
 Singularity will automatically disable this feature if the host does not support the prctl option `PR_SET_NO_NEW_PRIVS`. In addition, `enable overlay` must be set to `yes` and the host system must support overlayFS (generally kernel versions 3.18 and later) for users to bind host directories to bind points that do not already exist in the container. 
 
+### AUTOFS BUG PATH (string)
+With some versions of autofs, Singularity will fail to run with a "Too many levels of symbolic links" error. This error happens by way of a user requested bind (done with -B/--bind) or one specified via the configuration file. To handle this, you will want to specify those paths using this directive. For example:
+```bash
+autofs bug path = /share/PI
+```
 
 ## Logging
 In order to facilitate monitoring and auditing, Singularity will syslog() every action and error that takes place to the `LOCAL0` syslog facility. You can define what to do with those logs in your syslog configuration.

pages/docs/overview/faq.md

@@ -328,4 +328,19 @@ To add /usr/local/bin to the default sudo search path, run the program visudo wh
 ```bash
 Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
 ```
+
+### How to resolve "Too many levels of symbolic links" error
+Running singularity failed with "Too many levels of symbolic links" error
+
+```bash
+$ singularity run -B /apps container.img
+ERROR : There was an error binding the path /apps: Too many levels of symbolic links
+ABORT : Retval = 255
+```
+
+You got this error because /apps directory is an autofs mount point. You can fix it by editing singularity.conf and adding the following directive with corresponding path:
+```bash
+autofs bug path = /apps
+```
+
 {% include links.html %}

pages/docs/user-docs/docs-apps.md

@@ -113,7 +113,7 @@ To motivate the first need, let’s imagine a scenario where a researcher is dev
 The next need is driven by a larger goal of encouraging reproducible practices. At first glance, containers are a leap in the right direction. Given that all dependencies are packaged nicely, a container is very reproducible. Given this level of representation, a container gives the user absolutely everything - a complete operating system with data, libraries, and software. But this also means that we are producing heavy containers to serve a small amount of software. In terms of reproducibility, we have lost modularity because best practices implement a module on the level of an operating system, and not on the level of the software installed. There are several problems with this practice:
 
 - Containers are not consistent to allow for comparison. Two containers with the same software installed in different locations do not obviously do the same thing, despite this being a possibility.
-- Containers are not transparent. If i discover a container and do not have any prior knowledge or metadata, a known function may be completely concealed.
+- Containers are not transparent. If I discover a container and do not have any prior knowledge or metadata, a known function may be completely concealed.
 - Container contents are not easily parseable, or programmatically understandable. I should be able to run a function over a container, and know exactly the functions available to me, ask for help for a function, or how and where to interact with inputs and outputs.
 - Container internal infrastructure is not modular. We would be weary to export an entire container into another because of overlapping content.