University of Cambridge Computer Laboratory - Archive SMB service migration – Maintenance details

Archive SMB service migration

Scheduled for July 04, 2024 at 9:00 AM – July 06, 2024 at 2:31 PM


Data Storage

Under maintenance from 9:00 AM to 2:31 PM

Archive Server

Under maintenance from 9:00 AM to 2:31 PM

  • Completed
    July 06, 2024 at 2:31 PM
    July 06, 2024 at 2:31 PM
    Maintenance has completed successfully.
  • Update
    July 04, 2024 at 8:54 PM
    In progress
    July 04, 2024 at 8:54 PM

    All affected shares / volumes should now be available again.

    As previously communicated, the server name for SMB volumes has changed. Where you previously used a path starting with \\, you will now need to use \\

    Also as previously communicated, ownership of files and directories has been reset. Each share has been assigned an owning user or group, based on who we believe is using the share. The owning user or group has full control over the contents of the share; anyone not in the group has read-only access. Detailed permissions (ACLs) and other extended attributes have been removed. If you find that the new permissions are not behaving as you expect, please contact

    You are welcome to add ACLs to your shares again if you wish. They will be stored in a new format behind the scenes, but should work the same as they always did.

    Some further work is ongoing, for example to restore the use of snapshots.

    Please note that we anticipate having to install a software update on the new archive server within the next few days (unfortunately it was not available in time to install today), which will cause another brief outage.

    Users of corelab_datasets can now access their volume from Linux via NFS through the path /auto/archive/corelab_datasets. If it doesn't work, you may need to restart autofs once on your client: if you have root access, use "sudo systemctl restart autofs". Please discontinue the use of the old SMB-based path (/smb/...). In due course we will tidy up the SMB-based setup from those clients on which it has been set up. Thanks for your patience whilst we worked to improve the use of this volume for Linux users. Windows and Mac users can continue to use SMB via the new path \\\corelab_datasets.

    Users of scy27_traces can continue to use /auto/archive/scy27_traces but will now need a Kerberos ticket to do so. If it doesn't work, you may need to restart autofs once on your client: if you have root access, use "sudo systemctl restart autofs". You can also access the volume via SMB if needed.

  • Update
    July 04, 2024 at 12:07 PM
    In progress
    July 04, 2024 at 12:07 PM

    The part of today's work affecting NFS users of archive (other than scy27_traces which is a special case) is now complete. NFS volumes are available again. If you have problems with the archive NFS service, contact

    SMB / Windows-style volumes are currently unavailable and will be set up on the new archive server (archive-smb) during the rest of today and tomorrow.

  • In progress
    July 04, 2024 at 9:00 AM
    In progress
    July 04, 2024 at 9:00 AM
    Maintenance is now in progress
  • Update
    July 04, 2024 at 9:00 AM
    July 04, 2024 at 9:00 AM

    The SMB (Windows-style) storage service on will be moving to a new server and a new hostname. Users will need to change how they access the service. NFS users will be briefly impacted too at this time (and then the NFS service will move to the new server later). Details will be sent out by email and posted here in due course.

    The work will begin on 4th July, with follow-up work possibly extending into 5th July. Times are approximate at this stage but you should consider the service to be unavailable all day.

  • Planned
    June 17, 2024 at 6:00 PM
    June 17, 2024 at 6:00 PM

    Text of the email announcement:

    This message is meant for researchers who store data on the archive server,  Professional services staff can ignore this announcement.  Researchers who aren't sure whether they use archive can see below for some guidance on how to tell.

    The archive server,, is being replaced.  The server will be unavailable on one or two occasions (first one: 4th-5th July) whilst this work takes place.  You may then need to change how you access the server.

    How do I know if I am using archive?

    Most people are not using archive.  However if you contacted us asking for backup space or more than a few hundred gigabytes of storage at any point during the last several years, we might have provided you with storage on archive.  We would generally have discussed this with you when creating the storage, though in some cases that would have been many years ago.

    The archive server is not related to filer or bigdisc.

    Generally any access to archive will be through the hostname “” or simply “archive”, or paths including the component "archive" or "gfxdisp".  (The server name "berilia" is also involved; if you are using anything referring to "berilia" please contact as this will stop working.)

    Archive provides two separate services: NFS (Linux/UNIX style) shares and SMB (Windows-style) shares.  (SMB may also be referred to as CIFS.  SMB can be accessed from Linux clients too, though mostly it's intended for Windows.)  At the moment, both services use the same server name,  We will be migrating both services to a new server, but on different days.  However, all users of archive will be impacted to some extent on that day, and almost all users of archive will need to change how they use the service.

    You are using archive’s SMB (Windows-style) service, a.k.a. CIFS, if any of the following applies:

    • You are using path that look similar to any of the following:

      • \\archive\something or \\\something (Windows UNC paths)

      • smb:// or smb://archive/something (Linux/Mac file browser SMB paths)

      • // or //archive/something (UNC paths as used by some Linux clients such as “mount -t smbfs” or “mount -t cifs”)

    • You are using “corelab_datasets” (this is a special case; see below)

    • You are using “scy27_traces” (this is a special case; see below)

    If any of these apply, see "Impact on SMB users" below; expect a long period of disruption on 4th July, perhaps extending into 5th July, and to have to change how you access archive.

    You are using archive’s NFS (Linux/UNIX-style) service if any of the following applies:

    • You are manually mounting storage from or archive:/export/something, or have one of those paths in /etc/fstab

    • You are using paths under /auto/archive or /net/archive or /anfs/gfxdisp or /auto/anfs/gfxdisp

    If any of these apply, see "Impact on NFS users" below; expect a short disruption on 4th July, then another email about a longer disruption a month or two later.

    Impact on SMB users

    The SMB service will move first, on 4th July.  It will be unavailable for several hours on that day, potentially with disruption extending to the next day due to the large amount of work needed to reinstate this service on a new server.

    Immediately after the work on 4th July, the archive SMB service will move to  You will need to update any path that you use that currently refers to the SMB service on

    Access permissions on SMB shares will be reset!  For each SMB share, we have identified the current users and will grant those users read and write access to the entire share.  Every other member of the department will be given read access (in order to minimise disruption, as we believe there is no confidential data on archive).  If you have confidential data on archive that must not be readable by other users, please contact immediately.

    Any custom permissions that may have been set on individual files and folders will be lost.  Unfortunately it is not feasible to transfer permissions from the old server to the new one, as we are switching software platform (from Spectra Verde to TrueNAS) and the two platforms store Windows-style ACLs in different, incompatible ways.

    Whilst the permissions are being rebuilt on 4th-5th July – which is a manual process – you may find that you are unable to access your storage.  We will try to restore read access first; write access may take longer.

    If you are using corelab_datasets: This is a special case; it is a SMB (Windows) share, but several members of your group access it from managed Linux systems via a temporary mechanism.  We plan to make this share available via both SMB and NFS, to better support access from both operating systems.  We will reconfigure each managed Linux machine on which we’ve set up access to this dataset to use NFS, once this volume is available via NFS.  Until then, you will be unable to access corelab_datasets from Linux.

    If you are using scy27_traces: As discussed with the users (RT ticket #135996), this is currently a NFS share but is being migrated along with the SMB shares so that we can enable SMB access in future.  So this will experience the same disruption as SMB shares, described above, including the reset of permissions.  On 4th July it will also start to require a Kerberos ticket for NFS access.

    Impact on NFS users

    Firstly, on 4th July the NFS service will be unavailable for a short while (approximately 30-60 minutes) as the whole archive server will need to be shut down in order to move the disks holding SMB data to another server.  Preparatory work has already been completed to try to expedite this process; however there is a chance of unexpected problems with bringing the NFS service back online on the old server (due to complications with the old server's obsolete software platform).  We will prioritise bringing the NFS service back up as quickly as possible on 4th July.

    There will be a future more-disruptive outage to archive’s NFS service in a month or two when we move that service to the new hardware; the timeline for this is not yet decided.

    But if you are accessing an archive NFS filesystem from a Lab-managed Linux/UNIX system, you can prepare now for the migration by ensuring that you are not using a path starting /net/archive.  If you are using /net/archive/export/SHARE please switch to /auto/archive/SHARE as soon as convenient.

    If you are accessing an archive NFS filesystem from a non-Lab-managed computer by manually mounting archive[]:/export/SHARE, we suggest that you email now to ask that we help you to set up the Lab automounter on your computer.  If you don’t, you’ll have to change to a different path when we move the NFS service.

    At the moment, NFS shares on archive only support “sec=sys” (IP-address-based access); they do not use any form of strong authentication.  After the upgrade, we will be in a position to optionally authenticate NFS using Kerberos, as we do on filer.  Contact if you are interested in switching your archive NFS share to Kerberos.

    Updates during the work

    Updates on progress during the work (as well as a copy of this announcement) will be posted at .  You can subscribe on that page if you would like to receive updates by email.

    Please contact if you have any questions.  Thanks.