Think of mount points as windows between one server and another one. The share drive is a Windows server. We cannot set up mount points there, so there are no windows from the share drive into libcontent.lib.ua.edu, which is a SUSE Linux server. However, we have several mount points set up that allow us to look down into various parts of the share drive from libcontent.
This is extremely handy for moving large quantities of files or large files between the share drive and the libcontent server, as then they move across the network only once (between those servers). The alternative is that you move the files to your desktop and then up to the other server -- that is MUCH slower, will tie up your desktop so you can't use it, and puts the files at more risk, as they have to cross the network twice.
Each mount point serves a particular purpose, and "opens a window" into a different part of the share drive -- OR it opens a window to the same place, but with different libcontent permissions. Sometimes the permissions assigned are very important to allow the person/script using that mount point to be able to do what they need to do.
All the scripts that cross the mount point have expectations of what to find, and the share directories and files need to fill those expectations for the scripts to work. See Setting Up Metadata Librarian Work Area and Share_Drive_Protocols for more information.
When scripts hang up as soon as you try to run them, that usually means a mount point is down. To verify this, log in to libcontent (or open a separate shell window) and ls the root level:
If this hangs up, you have a mount point problem. Sometimes this resolves within a few minutes or so, on its own. If so, this command will finally print out what is at the root level of the server:
ls / archive cifs-mount cifs-mount12 cifs-mount3 cifs-mount6 cifs-mount9 home mariadb-staging opt sbin sys var bin cifs-mount10 cifs-mount13 cifs-mount4 cifs-mount7 dev lib media proc selinux tmp boot cifs-mount11 cifs-mount2 cifs-mount5 cifs-mount8 etc lib64 mnt root srv usr
As you can see, there are several mount points in use (the "cifs-mount" directories). If, when these results print out, one or more of these is a different color, you'll know you need to remount it/them.
You'll need sudo access (root access) to remount the mount points. If no one available has that access, contact someone who does (web services, or OIT support).
Before you can remount, you'll need to "clear the cache" by unmounting the problem point first. For example, if cifs-mount is down, type in:
You'll notice I gave the full path to the directory (add the "/" before it).
Then you can remount it, using the correct mount point. For each of the commands below, change the username to your username, and use your password for UALIB when it asks for your password.
Below are most of the current mount commands. NOTE: If the directory on the share drive that the mount point opens onto is removed, the mount point will break.
For Digital Services:
mount -t cifs -o uid=jeremiah,gid=www,username=jlderidder,domain=lib //libfs1.lib.ua-net.ua.edu/share/Digital\ Projects/ /cifs-mount mount -t cifs -o uid=ds,gid=www,username=jlderidder,domain=lib //libfs1.lib.ua-net.ua.edu/share/Digital\ Projects/ /cifs-mount11 mount -t cifs -o uid=jlderidder-local,gid=www,username=jlderidder,domain=lib //libfs1.lib.ua-net.ua.edu/share/ /cifs-mount12 mount -t cifs -o uid=cethomas1,gid=www,username=jlderidder,domain=lib //libfs1.lib.ua-net.ua.edu/share/Metadata/Staging/Celeste/MODSedits/ /cifs-mount6
For Metadata Librarians
mount -t cifs -o uid=malexand-local,gid=www,username=jlderidder,domain=lib //libfs1.lib.ua-net.ua.edu/share/Metadata/Staging/Mary/MODSedits/ /cifs-mount5
mount -t cifs -o uid=jeremiah,gid=www,username=jlderidder,domain=lib //libfs1.lib.ua-net.ua.edu/share/Special\ Collections/Digital_Program_files/EAD/ /cifs-mount2 mount -t cifs -o uid=jeremiah,gid=www,username=jlderidder,domain=lib //libfs1.lib.ua-net.ua.edu/share/Special\ Collections/ /cifs-mount4