apache/hadoop · error · IOException

${msg}. Consider using -skipTrash option

Error message

${msg}. Consider using -skipTrash option

What it means

IOException thrown by Rm.moveToTrash (Delete.java:163): 'hadoop fs -rm' first tries Trash.moveToAppropriateTrash (because trash is enabled, i.e. skipTrash==false); that call failed with an IOException that is NOT a FileNotFoundException. The shell appends the underlying message plus '. Consider using -skipTrash option', so the text before the suffix is the real cause.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/shell/Delete.java:163

          }
        }
      }
      return shouldDelete;
    }

    private boolean moveToTrash(PathData item) throws IOException {
      boolean success = false;
      if (!skipTrash) {
        try {
          success = Trash.moveToAppropriateTrash(item.fs, item.path, getConf());
        } catch(FileNotFoundException fnfe) {
          throw fnfe;
        } catch (IOException ioe) {
          String msg = ioe.getMessage();
          if (ioe.getCause() != null) {
            msg += ": " + ioe.getCause().getMessage();
          }
          throw new IOException(msg + ". Consider using -skipTrash option", ioe);
        }
      }
      return success;
    }
  }
  
  /** remove any path */
  static class Rmr extends Rm {
    public static final String NAME = "rmr";
    
    @Override
    protected void processOptions(LinkedList<String> args) throws IOException {
      args.addFirst("-r");
      super.processOptions(args);
    }

    @Override
    public String getReplacementCommand() {

View on GitHub (pinned to 2add963021)

Solutions

  1. Read the message before the suffix — it names the actual trash failure; fix that (usually permissions on /user/<user>/.Trash)
  2. If immediate deletion is acceptable, rerun with the flag the message suggests: 'hadoop fs -rm -skipTrash /path'
  3. Ask your admin to repair the .Trash hierarchy permissions, or recreate the checkpoint ('hadoop fs -expunge')
  4. For scripts where trash is never wanted, make -skipTrash the default and document it

Example fix

# before
hadoop fs -rm /data/stale-file      # trash failure text ... Consider using -skipTrash option

# after (immediate deletion acceptable)
hadoop fs -rm -skipTrash /data/stale-file
Defensive patterns

Strategy: fallback

Validate before calling

// probe trash before a batch of rm operations
Path probe = new Path(fs.getWorkingDirectory(), ".rm-probe-" + System.nanoTime());
fs.create(probe, false).close();
boolean trashWorks;
try {
  trashWorks = Trash.moveToAppropriateTrash(fs, probe, conf);
} catch (IOException ioe) {
  trashWorks = false; // plan on -skipTrash for this batch
}
fs.delete(probe, false);

Try / catch

try {
  success = Trash.moveToAppropriateTrash(fs, path, conf);
} catch (FileNotFoundException fnfe) {
  throw fnfe;
} catch (IOException ioe) {
  String msg = ioe.getMessage();
  if (ioe.getCause() != null) msg += ": " + ioe.getCause().getMessage();
  throw new IOException(msg + ". Consider using -skipTrash option", ioe);
}

Prevention

When it happens

Trigger: Trash enabled (fs.trash.interval > 0) but the trash checkpoint directory cannot be created: the user lacks write permission on /user/<user>/.Trash on HDFS; a .Trash path occupied by a file rather than a directory; filesystems whose trash support is limited (some object stores); a quota limit hit while moving into trash.

Common situations: Shared clusters where admins restricted /user directories; deleting with a proxy user whose home is not writable; migrations from local FS to s3a/abfs where trash semantics differ; trash checkpoint misconfiguration making the current checkpoint unusable.

Related errors


AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/c8cda17ec0d54009. Report an issue: GitHub.