Amazon Elastic File System
User Guide

Troubleshooting Amazon EFS

You can find information about how to troubleshoot the following issues for Amazon Elastic File System (Amazon EFS).

Troubleshooting Amazon EFS: General Issues

Use this information to troubleshoot general Amazon EFS issues. For information about performance, see Amazon EFS Performance.

In general, if you encounter issues with Amazon EFS that you have trouble resolving, confirm that you're using a recent Linux kernel. If you are using an enterprise Linux distribution, we recommend the following:

  • Amazon Linux 2

  • Amazon Linux 2015.09 or newer

  • RHEL 7.3 or newer

  • RHEL 6.9 with kernel 2.6.32-696 or newer

  • All versions of Ubuntu 16.04

  • Ubuntu 14.04 with kernel 3.13.0-83 or newer

  • SLES 12 Sp2 or later

If you are using another distribution or a custom kernel, we recommend kernel version 4.3 or newer.


RHEL 6.9 might be suboptimal for certain workloads due to Poor Performance When Opening Many Files in Parallel.

Amazon EC2 Instance Hangs

An Amazon EC2 instance can hang because you deleted a file system mount target without first unmounting the file system.

Action to Take

Before you delete a file system mount target, unmount the file system. For more information about unmounting your Amazon EFS file system, see Unmounting File Systems.

Application Writing Large Amounts of Data Hangs

An application that writes a large amount of data to Amazon EFS hangs and causes the instance to reboot.

Action to Take

If an application takes too long to write all of its data to Amazon EFS, Linux might reboot because it appears that the process has become unresponsive. Two kernel configuration parameters define this behavior, kernel.hung_task_panic and kernel.hung_task_timeout_secs.

In the example following, the state of the hung process is reported by the ps command with D before the instance reboot, indicating that the process is waiting on I/O.

$ ps aux | grep root 33253 0.5 0.0 126652 5020 pts/3 D+ 18:22 0:00 python /efs/large_file

To prevent a reboot, increase the timeout period or disable kernel panics when a hung task is detected. The following command disables hung task kernel panics on most Linux systems.

$ sudo sysctl -w kernel.hung_task_panic=0

Poor Performance When Opening Many Files in Parallel

Applications that open multiple files in parallel do not experience the expected increase in performance of I/O parallelization.

Action to Take

This issue occurs on Network File System version 4 (NFSv4) clients and on RHEL 6 clients using NFSv4.1 because these NFS clients serialize NFS OPEN and CLOSE operations. Use NFS protocol version 4.1 and one of the suggested Linux distributions that does not have this issue.

If you can't use NFSv4.1, be aware that the Linux NFSv4.0 client serializes open and close requests by user ID and group IDs. This serialization happens even if multiple processes or multiple threads issue requests at the same time. The client only sends one open or close operation to an NFS server at a time, when all of the IDs match. To work around these issues, you can perform any of the following actions:

  • You can run each process from a different user ID on the same Amazon EC2 instance.

  • You can leave the user IDs the same across all open requests, and modify the set of group IDs instead.

  • You can run each process from a separate Amazon EC2 instance.

Custom NFS Settings Causing Write Delays

You have custom NFS client settings, and it takes up to three seconds for an Amazon EC2 instance to see a write operation performed on a file system from another Amazon EC2 instance.

Action to Take

If you encounter this issue, you can resolve it in one of the following ways:

  • If the NFS client on the Amazon EC2 instance that's reading data has attribute caching activated, unmount your file system. Then remount it with the noac option to disable attribute caching. Attribute caching in NFSv4.1 is enabled by default.


    Disabling client-side caching can potentially reduce your application's performance.

  • You can also clear your attribute cache on demand by using a programming language compatible with the NFS procedures. To do this, you can send an ACCESS procedure request immediately before a read request.

    For example, using the Python programming language, you can construct the following call.

    # Does an NFS ACCESS procedure request to clear the attribute cache, given a path to the file import os os.access(path, os.W_OK)

Creating Backups with Oracle Recovery Manager Is Slow

Creating backups with Oracle Recovery Manager can be slow if Oracle Recovery Manager pauses for 120 seconds before starting a backup job.

Action to Take

If you encounter this issue, disable Oracle Direct NFS, as described in Enabling and Disabling Direct NFS Client Control of NFS in the Oracle Help Center.


Amazon EFS doesn't support Oracle Direct NFS.

Troubleshooting File Operation Errors

When you access Amazon EFS file systems, certain limits on the files in the file system apply. Exceeding these limits causes file operation errors. For more information on client and file-based limits in Amazon EFS, see Limits for NFS Clients. Following, you can find some common file operation errors and the limits associated with each error.

Command Fails with “Disk quota exceeded” Error

Amazon EFS doesn't currently support user disk quotas. This error can occur if any of the following limits have been exceeded:

  • Up to 128 active user accounts can have files open at once for an instance.

  • Up to 32,768 files can be open at once for an instance.

  • Each unique mount on the instance can acquire up to a total of 8,192 locks across 256 unique file-process pairs. For example, a single process can acquire one or more locks on 256 separate files, or eight processes can each acquire one or more locks on 32 files.

Action to Take

If you encounter this issue, you can resolve it by identifying which of the preceding limits you are exceeding, and then making changes to meet that limit.

Command Fails with "I/O error"

This error occurs when you encounter one of the following issues:

  • More than 128 active user accounts for each instance have files open at once.

    Action to Take

    If you encounter this issue, you can resolve it by meeting the supported limit of open files on your instances. To do so, reduce the number of active users that have files from your Amazon EFS file system open simultaneously on your instances.

  • The AWS KMS key encrypting your file system was deleted.

    Action to Take

    If you encounter this issue, you can no longer decrypt the data that was encrypted under that key, which means that data becomes unrecoverable.

Command Fails with "File name is too long" Error

This error occurs when the size of a file name or its symbolic link (symlink) is too long. File names have the following limits:

  • A name can be up to 255 bytes long.

  • A symlink can be up to 4080 bytes in size.

Action to Take

If you encounter this issue, you can resolve it by reducing the size of your file name or symlink length to meet the supported limits.

Command Fails with "Too many links" Error

This error occurs when there are too many hard links to a file. You can have up to 177 hard links in a file.

Action to Take

If you encounter this issue, you can resolve it by reducing the number of hard links to a file to meet the supported limit.

Command Fails with "File too large" Error

This error occurs when a file is too large. A single file can be up to 52,673,613,135,872 bytes (47.9 TiB) in size.

Action to Take

If you encounter this issue, you can resolve it by reducing the size of a file to meet the supported limit.

Troubleshooting AMI and Kernel Issues

Following, you can find information about troubleshooting issues related to certain Amazon Machine Image (AMI) or kernel versions when using Amazon EFS from an Amazon EC2 instance.

Unable to chown

You're unable to change the ownership of a file/directory using the Linux chown command.

Kernel Versions with This Bug


Action to Take

You can resolve this error by doing the following:

  • If you're performing chown for the one-time setup step necessary to change ownership of the EFS root directory, you can run the chown command from an instance running a newer kernel. For example, use the newest version of Amazon Linux.

  • If chown is part of your production workflow, you must update the kernel version to use chown.

File System Keeps Performing Operations Repeatedly Due to Client Bug

A file system gets stuck performing repeated operations due to a client bug.

Action to Take

Update the client software to the latest version.

Deadlocked Client

A client becomes deadlocked.

Kernel Versions with This Bug

  • CentOS-7 with kernel Linux 3.10.0-229.20.1.el7.x86_64

  • Ubuntu 15.10 with kernel Linux 4.2.0-18-generic

Action to Take

Do one of the following:

  • Upgrade to a newer kernel version. For CentOS-7, kernel version Linux 3.10.0-327 or later contains the fix.

  • Downgrade to an older kernel version.

Listing Files in a Large Directory Takes a Long Time

This can happen if the directory is changing while your NFS client iterates through the directory to finish the list operation. Whenever the NFS client notices that the contents of the directory changed during this iteration, the NFS client restarts iterating from the beginning. As a result, the ls command can take a long time to complete for a large directory with frequently changing files.

Kernel Versions with This Bug

CentOS kernel versions lower than 2.6.32-696.1.1.el6

Action to Take

To resolve this issue, upgrade to a newer kernel version.