Mount Points

From UA Libraries Digital Services Planning and Documentation
(Difference between revisions)
Jump to: navigation, search
Line 5: Line 5:
 
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.
 
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.
+
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:
 
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:

Revision as of 08:46, 30 June 2017

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:

  ls /

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:

   umount /cifs-mount

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   



For Archivists


 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
Personal tools