FAQs: Transfer and Sharing
What’s the difference between Globus and GridFTP?
Globus is software-as-a-service (SaaS) for file transfer, sharing, and data publication. It is a cloud-hosted service, operated by the Globus development team, that acts as a third-party mediator/facilitator for managing data on storage systems (or endpoints) that are owned and managed by their respective owners.
GridFTP is user-installable software that is part of the Globus Toolkit and is used by grid installers and developers building large-scale data movement solutions. Globus uses the GridFTP protocol for transferring files (HTTP support is planned for a future release).
Which browsers does the Globus web user interface support?
The Globus web user interface is tested and verified to work on the most recent desktop version of Chrome, Edge, Firefox, Internet Explorer, and Safari.
Earlier versions of these browsers, as well as other desktop browsers (e.g. Opera) and mobile/touch-based browsers, may experience loss of functionality and/or distorted visual effects. Limited or no support may be available for such browsers.
How do I "refresh my credentials" (or "activate an endpoint")?
Because Globus does not store usernames/passwords for your endpoints, periodic re-authentication is required. This means you need to log on with the appropriate username and password for the given endpoint (this is called endpoint "activation"). There are three ways to refresh your credentials in Globus:
Go to the Manage Endpoints page. Find the endpoint for which you need to renew credentials and click the "activate" link to re-authenticate.
Go to the Transfer Files page, and enter the endpoints you need. This should prompt you to log in so you can access the endpoint. If you had already begun a transfer when you discovered the need to renew credentials, you do not need to start a new transfer; just logging into the endpoint will be sufficient to refresh your credentials.
Login to command line interface (
ssh cli.globusonline.org) and use the
endpoint-activatecommand to refresh your credentials. For example, enter endpoint-activate nersc#dtn, and it should prompt you for your NERSC login and password.
You can refresh any credential from any network-connected computer at any time using the above mechanisms.
Globus Connect Personal endpoints do not need to be explicitly activated. If a Globus Connect Personal endpoint is part of an active transfer request, its credentials will be automatically refreshed as needed.
You do not need to resubmit a previously inactive transfer after you’ve reactivated the relevant endpoints; Globus will automatically resume transferring files when both the source and destination endpoints are activated.
If you are using GSI SSH to access Globus, you may just need to run the
transfercommand with the
-gargument. The same credentials which were used to authenticate to Globus will then be used to access your files on the endpoint (of course, the endpoint must be configured to map this credential to you local account). If you have used Globus in the past to access this endpoint successfully, the credentials used at that time have probably expired.
What does the error "Credentials are needed" mean?
It means Globus no longer has access to the endpoint(s) you are using because your credentials have expired. See the instructions above for ways to re-authenticate on the endpoint and refresh your credentials.
What is "activation"?
Activation is the mechanism Globus uses to authenticate a user on an endpoint. It enables users to specify which identity should be used to authenticate with an endpoint. For example if I wanted to transfer a file from NERSC to ALCF, I could sign in to Globus using my Globus account name and password, and activate the nersc#dtn+ endpoint using my NERSC username and password, and finally activate the alcf#dtn endpoint using my ALCF username and pin+OTP.
How do I see error logs for my transfers?
You can access a detailed list of errors (and other status messages) for any Globus Online task using both the Web interface and the command line interface.
Using the Web interface:
Click on the View Transfers page.
Click on the label of the transfer you would like to examine. You will see a popup with the transfer details.
Click on the "Event Log" tab to see a complete list of status messages. Note: this may be a very long list (potentially thousands of pages for a large transfer).
Using the command line interface (CLI):
statuscommand provides a summary of the transfer.
detailscommand provides additional information like start and end times, number of files transferred, and average transfer speed. Adding the
-tprovides information on each file in the task.
eventscommand lists the complete event log for the transfer (this command returns a very long list but you can use various command options to find the event(s) of interest).
All of the above commands have options that control the amount and format of the output returned. Please run
man for further details.
How do I check the status of my transfers?
How can I transfer files to and from my laptop or desktop?
Use Globus Connect Personal, which provides a point-and-click interface for configuring and operating a Globus endpoint on your local machine. After installing Globus Connect Personal, your computer looks just like any other Globus endpoint, so all the standard Globus web and command line interface features will work. Globus Connect Personal runs behind NATs and firewalls, as long as it can make an outbound connection. Click the link for your operating system to get started with Globus Connect Personal: Mac OS X, Windows, Linux.
How will I know when my transfer is completed?
Globus sends a notification message to the e-mail address stored in your account profile.
Which protocols does Globus support?
Globus uses the GridFTP and UDT protocols to transfer data. Support for HTTP/S is in development and will be available later in 2016.
What does "Beta" mean in the Globus context?
We use "Beta" as an indicator of what an end user may expect from a newly-released Globus feature. We will usually tag something as "Beta" when we have a new feature that we want to expose to users for feedback, but that we know is not fully tested and quality assured. When a Globus feature/page is tagged as "Beta" it means that we expect it to work as intended, but that you may experience some issues in your context. This means that we cannot provide performance guarantees and suggest that you not rely on the feature for production use.
What are GridFTP concurrency, pipelining, parallelism, and striping?
Globus optimizes GridFTP transfers by choosing performance optimizations based on the number and sizes of files in the workload. Thus, users do not have to be GridFTP and globus-url-copy experts to get high performance transfers. If you are an advanced user or resource owner, read on…
opens multiple login sessions (also known as control channel sessions). Each login session starts a GridFTP process on the server, usually via xinetd. Thus, a concurrency (cc) of 4 would drive 4 GridFTP processes, so you have 4 processes driving IO (each one working on a different file). Files are divided among the sessions, so this only works if you have multiple files in a job (most users do). Also note that each session may be to a different server if you had DNS round robining, a load balancer, or multiple physical endpoints defined in Globus. So concurrency is great for driving more filesystem processes, CPU cores, and even machine nodes, in addition to opening more network data streams.
speeds up lots of tiny files by stuffing multiple FTP commands into each login session back-to-back without waiting for the first command’s response. This reduces latency and keeps the GridFTP server constantly busy; it is never idle waiting for the next command. Note that a GridFTP server process currently only works on one command at a time (future protocol enhancements are planned to drive threaded, out of order processing of commands).
is a network level optimization. Regular FTP sends a file over one TCP stream, which isn’t ideal for high latency, high throughput links. Parallelism can divide and send a file’s data blocks over multiple TCP streams, however, all the TCP streams have the same source and destination GridFTP server process. Large files over high latency links can benefit from higher parallelism.
splits a single file’s data blocks across multiple servers. Globus does not support striping, based on the observation that most users are actually transferring more than one file and that an endpoint often serves multiple users concurrently. Striping can actually be counter productive in these cases, since it adds additional overhead and complexity, and the other options listed above deliver excellent performance.
Globus automatically selects appropriate settings for concurrency, pipelining, and parallelism on every transfer task - these may be overriden on per transfer or endpoint level.
How is www.globusonline.eu different from www.globus.org?
Globus cookies: https://www.globus.org/legal/cookie-types/
Managing your cookies: https://www.globus.org/legal/manage-cookies/
Are there any limits on using the file transfer service?
We enforce some limits on usage in order to provide reasonable performance to all users and protect against abuse. A Globus user is currently subject to the following limits:
3 active transfer tasks
100 pending transfer tasks
100,000,000 files in a single transfer task
5,000,000 files in a single directory
10 active sessions of the legacy hosted command line (CLI)
1,000 endpoints owned by a single user - this total includes both host endpoints
[A host endpoint is a standard endpoint created with Globus Connect Personal or Globus Connect Server]
and shared endpoints
[A shared endpoint is a share based on a host endpoint]
owned by the user
100 effective ACLs per user on an endpoint
[Of the 1000 total ACLs that may exist for a shared endpoint, no more than 100 of those can apply to any given user: when a user accesses the shared endpoint, the service finds all ACLs relevant to them either because of ACL against their identity or via their group membership. If the total ACLs there exceeds 100, an error is generated.]
1,000 total ACLs per endpoint
In addition, the Globus service will retain task details about events and completed files for up to 31 days.
The above limits are set based on our experience to-date and should accommodate the needs of most transfer users. If you have requirements that are likely to exceed these limits, please contact us to discuss.
How can I activate an endpoint for the maximum amount of time?
By default, the MyProxy service that ships with Globus Connect Server is configured to grant credentials with a maximum lifetime of 7 days. However, there are many endpoints that are configured to use values other than this default, and so such endpoints may have a maximum credential lifetime that is more or less than 7 days. For example, CILogon identity providers will typically grant credentials that have a maximum life time of 10 days.
It is not possible for an end user to be issued credentials that will last longer than the maximum credential lifetime for which an identity provider is configured. When authenticating on an endpoint that uses a MyProxy identity provider, you can specify the lifetime of the credential you are requesting. You can do this on the Globus command line interface by using the
endpoint-activate command with the
--myproxy-lifetime option, or in the web interface by clicking on the "advanced" link on the web page when prompted to authenticate to the endpoint. However, no matter what credential lifetime you request, you will never be issued a credential that is longer than the maximum credential lifetime than the MyProxy server is configured to issue. When activating on endpoints that use a CILogon identity provider there is no way to request a specific credential lifetime. Rather, you will simply be issued a credential with the default lifetime that the identity provider is configured to issue - typically 10 days.
Can I use Globus to manage identified data?
The security and privacy of identified data is regulated by a variety of mechanisms, such as the Health Insurance Portability and Accountability Act (HIPAA), state privacy laws, Institutional Review Board (IRB) requirements, National Institutes of Health (NIH) security best practices, and institutional policies, depending on the nature of the identified data and how the data are used, for example, research versus health care use. The suitability of Globus for managing sensitive data varies on a case by case basis, as determined by the organization charged with protecting the data, after consideration of a number of factors, including an analysis of risk and applicable regulatory laws and policies. We do not currently have the capacity to act as a Business Associate of a Covered Entity, however, we seek partners interested in working with us towards a common goal of a Business Associate Agreement.
Files managed by Globus never reside on Globus infrastructure. Files are located on storage resources that are provided and controlled by system owners and administrators, who also implement the file access control policies and permissions used by Globus. Files do not transiently reside on, or pass through, Globus infrastructure during transfer. Files are transferred through a channel that is established directly between Globus endpoints on the source and destination storage systems, and the Globus service does not have access to this channel. Globus does access file metadata, such as filename and size, for the purposes of monitoring transfer progress, security, and integrity. When transferring sensitive data, Globus users should opt to encrypt the transfer channel.
Please contact us if you would like to use Globus to manage sensitive data of any type. We are happy to help you determine if Globus can meet your needs for sensitive data management.
What is the Effective Transfer Rate reported by Globus?
The "Effective Transfer Rate" included in e-mail notifications and reported by the
details command is the ratio of number of bits transferred to the *total time taken to complete the transfer request*. The total time is calculated from the time the transfer request is submitted to Globus to the time the transfer is completed. It includes retry time, downtime on the endpoints, time that the transfer is paused for credential renewal, and time for checksum calculations. Hence, the Effective Transfer Rate indicates the time taken for reliable file transfer and should not be interpreted as raw bandwidth or throughput information.
For example, if your credentials on either endpoint expire and it takes you a few hours to renew them, that idle time is included in the transfer rate calculation and can result in relatively low Effective Transfer Rates even though the actual end-to-end throughput on the network is relatively high.
It is also worth noting that Globus allows each user to have up to three simultaneous transfers in progress, with additional transfers queued. If you submit more than three simultaneous transfer requests, the additional requests are queued while the three active requests are completed, and this queue time is also included in the Effective Transfer Rate calculation for those requests.
How do I control file permissions during transfers?
Globus does not preserve file permissions when performing a transfer. When you transfer files with Globus, their permissions are determined entirely by the destination endpoint’s configuration. There are still ways that you can control the permissions of the files created by Globus, on a destination endpoint, but they do not operate on information about the original file permissions.
Why We Don’t Preserve Permissions
An obvious question that arises is "Why doesn’t Globus preserve permissions?" This behavior is an unfortunate result of the fact that it is not entirely clear what preserving permissions means for some transfer tasks.
The Ideal Treatment of Permissions
Ideally, given endpoints user#A and user#B, with files in user#A, then transferring those files back and forth between user#A and user#B would not alter the permissions of those files. So, if we submitted a transfer task, copy user#A:/p/q/r to user#B:/x/y/z, the file at user#B:/x/y/z will have exactly the same permissions as the original at user#A:/p/q/r. Consider a second transfer in the other direction, copy user#B:/x/y/z to user#A:/p/q/r_prime. Since this should share the same property as the previous transer, user#A:/p/q/r and user#A:/p/q/r_prime should be completely indistinguishable — there should be no way to tell which one is the original by content or permissions.
The Problem With Ownership
But what if the user authenticates to user#A as a user with read permissions to user#A:/p/q/r, but not ownership? Then when the file is transferred back to user#A:/p/q/r_prime, the ownership will have changed. On most systems, only the superuser can change the owner of /p/q/r_prime to match /p/q/r. This is the basic issue with attempting to preserve ownership for files.
The Problem With Permissions Bits
Not all permissions settings are supported on all platforms. Consider what happens if user#A:/p/q/r has UNIX octal permissions 0111 — anyone can execute the file, but no one can read or write it — and user#B is a Windows endpoint. When the file is stored in Windows as user#B:/x/y/z, it can’t be given these same permissions because Windows does not support execute-only files. When user#B:/x/y/z is transferred to user#A:/p/q/r_prime, the only way for the transfer task to know to restore the original permissions is to keep track of all permissions of files transferred by Globus in case they are transferred again. Even with that extra information, it is difficult to know exactly what to do: what should Globus do if the file has been altered, or had permissions added or removed?
What if the file is moved with scp from user#B:/x/y/z to user#C:/w/t/u and with Globus from user#C:/w/t/u to user#A:/p/q/r_prime? Because permissions schemes are not uniform across all platforms, and files may move locally or remotely by means other than the Globus service, we cannot guarantee the transitivity of permissions across a series of transfers.
What Can You Do?
Having stated that the permissions of your files cannot be consistently preserved by Globus for technical reasons, what recourse do you, as a user or endpoint administrator, have? Our team is always looking to improve Globus, and better permissions handling is on the To Do List. In the meantime, however, you can make some steps to better control your file permissions.
Further Restricting Permissions for Globus Connect Server
By default, the GridFTP server uses the system umask setting to determine the permissions of all files that it creates. There is an option, passed either through the command line as "-perms", or through the config file (by default, placed in
/etc/gridftp.conf ) as a line "perms <value>", which can be used to further restrict the permissions of new files. The option is specified as a three digit octal integer, as typical UNIX permissions are, and is documented in the Globus Toolkit 5.2 release here.
"perms" does not override the umask, but is applied additively. Note that the "perms" option is written as a positive set of permissions bits, which are desired for new files, while the umask is a negative set of bits, which are forbidden. Since the GridFTP server attempts to create files with the "perms" permissions, the effective permissions of a new file are
<PERMS> AND (NOT <UMASK>) for regular files, rather than the default of
0666 AND (NOT <UMASK>). "perms" will not alter directory permissions, so those should still be
0777 AND (NOT <UMASK>).
Because the "perms" value is ANDed together with the inverted umask, it cannot be used to apply wider permissions than the umask allows, but it can be used to further restrict access. For example, if the system umask is set to
0002, but you want to forbid world read access and group write access to files, you could set "perms" to
0042. The resulting permissions, in this case, would be
0042 AND (NOT 0002) = 0042 AND (0775) = 0040, as the umask forbids the world write permission granted by "perms".
Using Filesystem ACLs
Because Globus delegates operations to the endpoint’s filesystem without inspecting ACLs on the source or destination, you can leverage your endpoint’s support of ACLs to control permissions tightly. By setting ACLs on the destination such that they are applied to all new files in a directory tree, you can effectively set ACLs on the files created by the GridFTP server. GridFTP and Globus will never attempt to explicitly get or set the filesystem ACLs, effectively leaving their application up to the destination endpoint’s filesystem implementation. Since different filesystems and operating systems may implement ACLs differently, we do not provide explicit instructions for any particular local ACL setup.
Setting the umask
Setting the umask explicitly is the only way to increase the permissions offered on files created by the GridFTP server. The most consistent and successful way to do this is to alter the Globus Connect Server init script to set the umask immediately before launching the GridFTP server. Most typically, the script is found in /etc/init.d/globus-connect-server
If you do not feel comfortable modifying the init script, this option is likely a bad choice for you. The init script is the only supported way of launching GridFTP for a Globus Connect Server installation, so damaging alterations to the script could prevent you from launching Globus Connect Server altogether. (In other words, choose this option at your own peril.)
Controlling Permissions for Globus Connect Personal
The above techniques can be applied to Globus Connect Personal, but there are some caveats. Most notably, we do not officially support modified versions of the Globus Connect Personal client, so if you alter any files or configuration within the client application in order to achieve your desired permissions scheme, your endpoint will not necessarily qualify for support from Globus staff. At present, none of the forms of Globus Connect Personal support specifying "perms" to the GridFTP server.
If you are running Globus Connect Personal for Linux, you may have some success altering your personal umask setting before launching the application, as your umask should propagate down the process tree to the GridFTP server process. Likewise, if you are running Globus Connect Personal on Mac OS X, you may be successful setting your umask before launching the Globus Connect Personal app through the command line. These actions are not guaranteed to be successful based on the exact behavior of your platform. Because Windows does not support a umask equivalent, there is no way to replicate this behavior in Globus Connect Personal for Windows.
When supported by your platform, filesystem ACLs are respected, but they are not an option for all users.
Use Globus Shared Endpoints
In many situations, restricting read or write access to a file can be handled correctly using Globus controlled Read and Write permissions on a Shared Endpoint. This does not alter the underlying permissions of the files, but restricts permissions when using a Globus account to access the endpoint. Globus will deny users without the Read permission the rights to copy files or list directory contents, and denies users without the Write permission the rights to copy a file to the specified path or directory.
These permissions settings do not alter the underlying endpoint’s permissions scheme in any way, so users with local access to the endpoint may be able to bypass these permissions settings by accessing files directly. If you know that your files are only exposed via Globus, then this option may be right for you.
How Does Globus Handle Symlinks?
At present, Globus skips symlinks in a wide class of transfers. The reason for this is that there are several notions of correct behavior for transfers of symlinks, especially with respect to their interaction with path restrictions in an endpoint’s configuration. However, symlinks are not uniformly ignored, and in some actions, for which the behavior on symlinks is unambiguous, they will be followed.
This behavior is identical between Globus Connect Personal and Globus Connect Server.
When listing the contents of a directory, if the path includes symlinks, those symlinks will be followed. However, when the links are followed, they do not receive special treatment — to Globus, they are considered indistinguishable from the directories to which they are links. This is very similar to the treatment of symlinks when doing local directory listings (i.e. ls in most shells), in which the fact that a directory is a link is not necessarily exposed.
So, if you have a symlink /tmp/myhome → /home/username/, then when you attempt to list the contents of /tmp/myhome/Desktop/, Globus will return a list of contents of /home/username/Desktop/. Globus will not give any indication that /tmp/myhome is a symlink; there is no path rewriting or other indication that /tmp/myhome is anything but an ordinary directory whose contents happen to be identical to /home/username/.
Recursive Directory Transfers
When doing a recursive directory transfer, all symlinks in the directory tree are ignored. The one and only exception to this rule is the root of a directory transfer.
Consider the previous example, /tmp/myhome → /home/username/. Doing a recursive directory transfer with a root directory of /tmp/myhome will transfer all of the contents of /home/username/, following the symlink /tmp/myhome. However, a recursive directory transfer on /tmp will skip /tmp/myhome, not creating it as a directory, link, or file on the destination. Furthermore, this skipping behavior does not trigger any errors, faults, or warnings in the transfer history, as it is not considered an error condition.
Single File Transfers
Single file transfers follow the same basic rules that directory transfers do, in that they dereference symlinks to their destination files, and create the link on the destination as an ordinary file.
If I have a link, /a/b/c → /p/q/r on my filesystem to an ordinary file, then transferring /a/b/c to another endpoint will behave as though the contents of /p/q/r were stored in /a/b/c, not giving any special treatment to /a/b/c or /p/q/r on account of its status as a link.
File and Directory Deletion
Globus does not follow symlinks when doing file or directory deletions. However, following the semantics of a typical UNIX rm command, Globus will unlink symbolic links by deleting them during a directory or file removal.
Symlinks and Path Restrictions
Globus endpoint configuration supports restricting the parts of the filesystem that can be accessed via Globus. In Globus Connect Server and GridFTP this corresponds to the RestrictPaths and SharingRestrictPaths options. By default, these settings apply to non-symlinked files and directories, not allowing access when a symlink points outside of the explicitly allowed components of the filesystem.
This behavior prevents abusive symlinks from breaking out of the path restrictions. Consider the case of an endpoint which only allows access to /p/q/r/, and a symlink /p/q/r/root → /. If symlinks are followed irrespective of the path settings, /p/q/r/root/home/ would be accessible, even though /home/ is not included.
If you trust users with access to an endpoint not to create this kind of exploitative symlink, you can override this behavior on Globus Connect Server endpoints with the
rp-follow-symlinks option to the GridFTP server. This option is not readily available with Globus Connect Personal installations.
How do I link directly to Globus application pages?
Many of the pages in the Globus application can be linked with parameters that allow the page to open pre-configured for your needs. When you link to a Globus application page, the application will ensure that the user is logged in to the Globus website (and prompt the user to authenticate if the user is not already logged in). If you have a specific use case or application feature that isn’t covered in this document please let us know at firstname.lastname@example.org.
What follows is a list of pages that are configurable.
Transfer Files (/app/transfer)
The Transfer Files page provides the following parameters to preselect the two sides of the Start Transfer page:
origin_id - represents the id of the endpoint for the left hand side of the page.
origin_path - represents the path of the endpoint for the left hand side of the page.
destination_id - represents the id of the endpoint and path for the left hand side of the page.
destination_path - represents the path of the endpoint for the right hand side of the page.
Endpoints which are specified on the URL in this fashion will require activation if they are not already activated by the user. You can determine the parameters and link by setting the desired endpoint(s) on the transfer page and selecting "get link" from the function menu.
Sends the user to the Start Transfer page with the endpoint Globus Tutorial Endpoint 1 selected on the left side.
Sends the user to the Start Transfer page with the endpoint Globus Tutorial Endpoint 1 selected on the left side and Globus Tutorial Endpoint 2 on the right.
Sends the user to the Start Transfer page with the endpoint Globus Tutorial Endpoint 1 and the path /share/ selected on the left side.
The groups page can be set up to automatically view a specific group by specifying the group id in the URL. For example the "Demo Group" group has an id of 7e183f30-e177-11e5-ba63-22000ab80e73, so the URL to automatically link to this group is "https://www.globus.org/app/groups/7e183f30-e177-11e5-ba63-22000ab80e73". Groups with visibility policies that prevent visibility to non Globus members will display an error page if the user utilizing the link does not meet the visibility requirements. You can determine the group id and link by selecting the desired group on the groups page and selecting "get link" from the function menu.
The groups page also has a function for displaying the "administrative queue" (/app/groups/messages) which is a list of all the groups that have actions requiring the user’s attention. It cannot be used in conjunction with the id at this time.
For a specific endpoint, go to https://www.globus.org/app/endpoints/<uuid>/activate. To see all endpoints that the user has credentials that are being used for active transfers and about to expire, go to https://www.globus.org/app/endpoints?reactivatable=1&scope=in-use.
Can I disable email notifications?
Currently, users can, through the Command Line Interface (CLI) only, turn off email notifications by running the following command:
$ profile -n off
Why is my transfer stalled?
There are several reasons a transfer may stall. You may want to start by seeing what Globus is doing with the request.
On the web, go to the "View Activity" page
Click on ID of specific transfer (probably the one at the top of the list)
Click "View Event Log".
Look through the progress messages and see if any of them indicate an error, such as an expired credential or quota exceeded.
In the CLI, the
status command will give you a high level overview of the progress of the task. If you run
status and find the task is not progressing, run the
events command. The following will show the most recent 5 events for the specified task:
$ events -l 5 <TaskID>
status command shows the task is inactive, you may need to refresh your credentials. See this FAQ item for information on how to do this.
What does the error "Directory contents cannot be found" mean?
Globus Connect Personal for Windows may have a problem automatically locating your user directory. Try manually entering "/" (just forward slash, no quotes) as the directory, and then you should be able to browse. Your c: drive would be "/cygdrive/c", and your user directory would be either "/cygdrive/c/users/<username>" or "/cygdrive/c/documents" and "settings/<username>".
Why did my transfer expire?
Globus will make every attempt to complete a Transfer request but sometimes may be unable to do so, based on factors outside of our control. For example, occasionally, an endpoint may stop responding (due to server failure, network issues, etc.). In this case, you will receive notifications about the error and should follow up with your system administrator.
A more common cause is "credential expiration". This means that Globus is no longer authorized to access the endpoint on your behalf to execute/manage your transfer. When this happens, Globus will send you an e-mail notification and suspend the transfer task until you renew your credentials for the endpoint. If the credentials are not renewed (i.e. the endpoint is not reactivated) within 3 days of the notification being sent, the transfer task will automatically expire.
Instructions for renewing your credentials are available here.
How do I resubmit a failed transfer?
If your transfer task has failed you should first look at the last few events in the event log to identify any problems needing human intervention (quota exceeded, out-of-disk space, etc.)
After fixing problems you can resubmit your task as follows:
. Using the Web GUI, go to the Start Transfer page, select the "more options" link at the bottom, and select the "only transfer new or changed files where the checksum is different" and "verify file integrity after transfer" checkboxes.
. Using the CLI, rerun the transfer command with the
-s 3 options
What characters should I avoid in filenames/paths?
On different filesystems, directory names and filenames may be restricted to certain characters. For instance, following character are reserved on ext2, ext3, ext4, hfs, FAT, NTFS:
|ext2, ext3, ext4 (Linux)|
|hfs (Mac OS X)|
|FAT, NTFS (MS Windows)|
||||vertical bar or pipe|
If a file or a directory with one of the characters <>:"\|?* is copied from Linux to MS Windows, then MS Windows will return the error message "The filename, directory name, or volume label syntax is incorrect" and refuse to create the file or the directory.
Also the filesystems FAT, NTFS, hfs are not case sensitive. It means that if two files on ext2, ext3, ext4 are different by case and they are transferred to a non-case sensitive filesystem they will be copied into one file.
How does Globus handle performance tuning on transfers?
Globus tunes transfers based on the number of servers of the source and destination endpoints, the location of the endpoints, and the performance options configured for each managed endpoint in your provider subscription. See the CLI
endpoint-modify man page for more details on the
--network-use performance option. Note that these options cannot yet be set via the Web UI or REST API.
How does load balancing work in endpoints with multiple servers?
Globus can load balance across servers when a task has more than one file (you might need about 10 files or so in a task.) Also, multiple tasks running at once might be load balanced across servers; the first task begins on a random server, with subsequent tasks assigned to other servers in a round robin fashion.
Can I use Globus to transfer data to/from any anonymous FTP server?
Globus can be used to transfer data to/from anonymous GridFTP servers (but not anonymous FTP servers). The service supports transfers between two anonymous GridFTP servers or between an anonymous GridFTP server and a standard GridFTP server. Follow the instructions below for your particular case:
Between two anonymous GridFTP servers:
$ endpoint-add anon-endpoint1 -p ftp://host1:port $ endpoint-add anon-endpoint2 -p ftp://host2:port $ endpoint-activate anon-endpoint* -m myproxy.globusonline.org $ scp anon-endpoint1:/path_to_src_file anon-endpoint2:/path_to_dst_file
Between a anonymous GridFTP server and a standard GridFTP server:
$ endpoint-add anon-endpoint -p ftp://host:port $ endpoint-add std-endpoint -p gsiftp://host:port $ endpoint-activate anon-endpoint -m myproxy.globusonline.org $ endpoint-activate std-endpoint -m myproxy-server-associated-with-std-gridftp-server $ scp anon-endpoint:/path_to_src_file std-endpoint:/path_to_dst_file
How long does Globus store transfer task history?
Globus will store a basic summary of a user’s task history indefinitely. Task details such as Task ID, Task Status, Source and Destination Endpoint Display Names for the task, Task Transfer Settings, and many other details are preserved indefinitely. Certain specific details for tasks are only stored for 30 days and then these details expire. These task details include the faults logged for the task as well as the status information concerning the individual files and directories involved in the transfer task.
From the web interface, users can access their task history at the following URL:
The task details under the "Event Log" tab for a given task are those that will expire after 30 days. All other details for a task will remain available indefinitely.
From the Globus CLI, users can access their task history with the
globus task show command like so:
globus task show TASK_ID
The above will show the basic details for the task that will be preserved indefinitely. Users can see more detailed information on their task by using the
globus task event-list command like so:
globus task event-list TASK_ID
The details returned by the
globus task event-list command show the job details that are preserved for only 30 days, and thus this command will return nothing for tasks more than 30 days old.