Skip to main content


JuiceFS keeps deleted files in Trash for a certain period of time before the actual deletion from object storage. Files remain billable even in Trash. Users may restore or delete files from Trash in JuiceFS console.


Trash not only protect files against accidental deletion, as a matter of fact, all forms of data modification is protected by trash, including file content overwrites. Read trash and file fragments to learn more.

Trash is automatically enabled when users create a file system. Default expiration is 1 day for free plan, 7 days for professional plan. Users may modify this setting in JuiceFS Console.

Move files to Trash

Execute the rm command in shell, target files will be moved into the Trash directory. But when it comes to deleting large amount of files, we recommend using juicefs rmr, this command deals with metadata directly (bypassing POSIX API), thus is much faster.

Being moved to Trash, these files will no longer be a part of the original directory, but the actual data is still kept in object storage. If the path of deleted files already exists in Trash, multiple versions will be kept.

Note that Trash does not apply to the following conditions:

  • Trash is only valid for files, the directory will be deleted immediately. When restoring files, the original directory structure is restored, but the previous directory attributes cannot be maintained. In particular, if an empty directory is deleted, it cannot be recovered.
  • Trash does not apply to the command juicefs snapshot -d <path> which will delete the snapshot immediately instead of moving it to Trash. However, snapshot deleted using rm <path> will be moved to Trash instead.
  • Trash does not apply to files created by juicefs import. The metadata of the imported files will be deleted immediately, while the content in object storage is not affected.

Empty Trash

Files remain billable even in Trash (object storage, too). Users can manually delete files from trash in the Web Console, navigate to the trash tab in the file system page, and delete files from there.

Once deletion is submitted, file metadata will be marked stale at the metadata service, and cease being billable. But know that the object storage blocks will remain and always be scheduled to garbage collection according to the trash expiration time at which files are deleted. Changing expiration time after deleting files from trash will not affect object storage deletion schedule for files previously deleted. As for on-premise deployments, Trash behavior can be tuned to handle situations where object storage data need to be quickly deleted.

For files already deleted, chunks in object storage are not deleted strictly according to its expiration time, instead, they'll be schedule for execution in clients, as background jobs. That's why at least one JuiceFS Client must be started (must not disable background job) for trash expiration to function correctly. All JuiceFS Client (FUSE mount, Hadoop Java SDK, and S3 Gateway) behaves roughly the same way in this regard. If no JuiceFS Client is running at all, files in trash will not be expired and garbage collected.

Restore from Trash

Users can restore files from Trash in JuiceFS Console

  1. Switch to the "Trash" tab in the file system page
  2. Select one or more files to be restored
  3. Click "Restore" button

If a massive directory is accidentally deleted, it'll be difficult to restore via mouse clicks on the Web Console. You need to operate directly in the .trash directory under the root of the mount point. Assuming mount point being /jfs, refer to below recovery steps.


ls output is different for trash, which looks something like:


The pipe sign | is merely a display optimization, original directory structure and filename will be restored when you move files out of directory

Due to this pipe sign problem, you should single quote your shell arguments when operating on trash files, or the pipe sign will be misinterpreted by the shell, causing errors.

# If .trash directory is not found, upgrade JuiceFS Client and remount
cd /jfs

ls .trash

# List all files that contain xxx in their absolute path
ls '.trash/xxx'

# Recover all files that contain xxx in their absolute path
mv '.trash/xxx' .

# Recover all files that contains tar.gz
mv '.trash/tar.gz' .

If you need to perform recovery using more complicated conditions, use the find command:

# The ctime (change time) stands for deletion time, you can recover files deleted during a period of time.
# The following command means to restore all files with ctime greater than 2023-12-12 17:30:00 and less than 2023-12-13 23:00:00
find .trash -newerct "2023-12-12 17:30:00" ! -newerct "2023-12-13 23:00:00" -exec mv {} . \;

# Recover all tar.gz files
find .trash -name '*.tar.gz' -exec mv {} . \;

# Recover all tar.gz files under mydir
find .trash -name '*|mydir|*.tar.gz' -exec mv {} . \;

# Recover all directory that's named mydir
find .trash -wholename '*|mydir|*' -exec mv {} . \;

# Recover mydir/text.txt
find .trash -wholename '*|mydir|text.txt' -exec mv {} . \;

When recovering files from trash, know that:

  • When recovering a large amount of files (over 100 thousands) via command line tools, there's possibility of misses and you should execute the recovery from our web console. If you absolutely need to use command line tools, you should compose the filter condition (demonstrated above in the code snippet) and then run repeatedly to ensure integrity.
  • The parent directories of the files will be created automatically and owned by root (similar to sudo mkdir -p), which might be different from the original ownership and permissions and needs manual adjustment.
  • If the path of file to be restored already exists, the restore operation will append a sequence number to the file name to avoid name collision, such as the file /a/b/c.txt in trash will be restored to /a/b/c.txt-1.
  • If multiple files are selected to restore, they will be restored in the listed order. Files whose path conflict with the ones restored before them will be skipped.