How to Use the Linux fuser Command to Find Processes Using Files, Mounts, and Ports

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

fuser answers a practical question: which process is using this resource? Give it a file, mounted file system, device, or TCP/UDP port and it reports the associated process IDs. Use a read-only, verbose query first; add privileges only when visibility is incomplete; and treat -k as a deliberate process-termination operation, not a diagnostic shortcut.

What the Linux fuser command does

The Linux manual defines fuser as a command that “displays the PIDs of processes using the specified files or file systems.” A target can be an ordinary path such as /var/log/app.log, a block device, a mount point, or a network socket. The command returns zero when it finds at least one access and a non-zero status when no named file is accessed or a fatal error occurs.

#	Preview	Product	Price
1		The Linux Command Line, 3rd Edition: A Complete Introduction	$27.94	Buy on Amazon
2		The Linux Command Line, 2nd Edition: A Complete Introduction	$11.34	Buy on Amazon
3		Linux Command Line: A Simple Beginner’s Guide to Linux Commands and Terminal Basics	$1.99	Buy on Amazon
4		Linux Pocket Guide: Essential Commands	$19.75	Buy on Amazon
5		Linux Command Reference Guide: 500+ Essential Commands and Examples for Everyday Use (Rheinwerk...	$33.91	Buy on Amazon

The basic form is:

fuser [options] name...

Each name is checked independently. With normal output, a target is followed by process IDs and access letters. The letters describe how a process is using the target:

When you need names, users, and access details rather than just PIDs, use verbose mode.

#1 Best Overall

Sale

The Linux Command Line, 3rd Edition: A Complete Introduction

$27.94

Buy on Amazon

Start with a safe, read-only inspection

Inspect one file and show the owner

Run:

fuser -v -u /path/to/file

The -v option adds a ps-like report with columns such as PID, USER, COMMAND, and ACCESS. The -u option appends the process owner’s user name. This is the best first command when an editor, backup job, daemon, or shell appears to be holding a file open.

For example, replace the path with the file that cannot be renamed, deleted, or replaced:

fuser -v -u /var/log/app.log

Read the command column before taking action. A shell may be using a directory as its current working directory, while a service may have the file open for writing. Those cases have different safe remedies.

Report every operand, including unused ones

By default, output focuses on names for which access was found. Add -a when you need every operand represented:

fuser -av /path/to/file /another/path

This is useful in scripts and investigations where an explicit “no process found” result for one of several paths matters. It also prevents an unused path from disappearing silently from a human-readable report.

Use quiet mode for a yes-or-no test

The -s option suppresses normal output. The exit status then tells a script whether the resource is in use:

Rank #2

The Linux Command Line, 2nd Edition: A Complete Introduction

$11.34

Buy on Amazon

if fuser -s /dev/ttyS1; then
  echo "in use"
else
  echo "available"
fi

A zero status means at least one access was found. A non-zero status means no named file was accessed or that a fatal error occurred, so scripts should distinguish “not in use” from an operational failure when the distinction is important.

Find processes preventing a file system from unmounting

Check the whole file system with -m

For a mounted file system, use:

fuser -vm /mnt/data

-m reports processes accessing files on the file system that contains the supplied name. The name can identify a mount point, a directory on that file system, or another path located there. Verbose mode is particularly important for mount investigations because it exposes access details, including kernel-related entries that are not shown in terse output.

Require an actual mount point with -M

If your intention is specifically to inspect an existing mount point, add -M:

fuser -vmM /mnt/data

-M prevents fuser from treating an ordinary file as a file-system target. The Linux manual describes this check as an “invaluable seat belt.” It is a sensible safeguard in scripts and in commands assembled from user-supplied paths.

A practical unmount workflow

1. Identify the exact mount. Confirm that /mnt/data is the mount point you intend to detach, rather than a directory inside another file system.
2. Inspect users without killing anything. Run fuser -vmM /mnt/data and record each PID, user, command, and access type.
3. Interpret the access. A process with c may simply have its current directory inside the mount. A process with a writable file open needs a more careful shutdown than a process that only read a file.
4. Stop the owning application normally. Use the service’s normal shutdown or ask the user to leave the directory. This allows buffers and application state to be flushed.
5. Recheck the mount. Run the same verbose command again. Continue only after confirming which PIDs remain and why.
6. Unmount once clear. Use your system’s normal unmount command after the report no longer shows active users. If the list is unexpectedly empty, investigate permissions and mount namespaces before assuming the mount is idle.

Do not infer that a mount is safe to detach merely because one particular directory looked unused. A process can hold a file elsewhere on the same file system, keep the mount as its current directory, or access it through a memory mapping.

Find the process listening on a TCP or UDP port

Query TCP and UDP explicitly

Select the socket namespace with -n:

fuser -v -n tcp 80
fuser -v -n udp 53

The first command identifies processes associated with TCP port 80; the second checks UDP port 53. You can also use a service name where the system’s service database provides one, or use the compact target form:

Rank #3

Linux Command Line: A Simple Beginner’s Guide to Linux Commands and Terminal Basics

$1.99

Buy on Amazon

fuser -v 80/tcp

By default, both IPv4 and IPv6 sockets are considered. Restrict the search when you need one address family only:

fuser -4 -v -n tcp 80
fuser -6 -v -n tcp 80

Verbose output lets you associate the PID with a user and command instead of guessing from a number alone. If a port appears free but a service is expected to be listening, check both protocols and both address families before concluding that nothing is bound.

Use a port check in automation

Quiet mode also works with network names:

if fuser -s -n tcp 8080; then
  echo "TCP port 8080 is in use"
else
  echo "TCP port 8080 is not reported as in use"
fi

The result answers whether fuser could see an access. It is not a guarantee that every process on the host was visible to the calling user; permission and namespace boundaries can affect the result.

Understand output before acting

PID is an identifier, not a diagnosis

A PID tells you which process entry matched the target. Use the USER and COMMAND columns from -v -u to establish ownership and purpose. A PID can be reused after a process exits, so do not save a number for later and assume it still refers to the same program.

Access letters explain why a resource is busy

The difference between a current directory, executable, ordinary open file, writable open file, root directory, and memory mapping affects the remedy. For example, asking a shell to change directories may release a mount without stopping the shell, while terminating a process that is writing a database file can cause interruption or data loss.

Kernel accesses require verbose reporting

Kernel accesses are shown only with -v. Include verbose mode when diagnosing a mount or device that remains busy even though no obvious user process appears to hold a file open.

Rank #4

Sale

Linux Pocket Guide: Essential Commands

$19.75

Buy on Amazon

Permissions, namespaces, and incomplete results

Why an unprivileged query can be empty

fuser may gather only partial information without appropriate privileges. The Linux manual warns that it may not inspect other users’ file-descriptor tables, and that TCP/UDP lookups run as an unprivileged user can report no access even when another process is using the socket. POSIX likewise states that a user may need appropriate privileges to invoke fuser.

If the result conflicts with what you observe, treat visibility as the first suspect. Retry with the least additional privilege allowed by your system policy, for example:

sudo fuser -v -u /path/to/file
sudo fuser -v -n tcp 80

Use elevated access for the inspection that needs it, not automatically for every command. Record who ran the command and what privilege level was used when results are part of an incident or change record.

Mount namespaces can hide block-device users

Block devices mounted in another mount namespace may not be visible from the namespace where you run fuser. This occurs on systems using containers, service isolation, or other namespace-based layouts. If a device appears busy from the host’s perspective but the report is empty, check which namespace contains the mount and run the inspection where the relevant processes and mount are visible.

Namespace isolation and insufficient privileges can produce the same symptom: no listed PID. An empty report therefore means “nothing visible to this invocation,” not automatically “nothing is using the resource.”

Using fuser -k without creating a larger problem

What -k does

-k sends a signal to every process that fuser selected for the target. Unless you choose another signal, the default is SIGKILL. SIGKILL cannot be caught or handled by the target process, so it does not provide an opportunity for normal cleanup, buffer flushing, or application shutdown.

Best Value

Sale

Linux Command Reference Guide: 500+ Essential Commands and Examples for Everyday Use (Rheinwerk Computing)

$33.91

Buy on Amazon

For that reason, never make -k your first diagnostic command. First run a verbose, owner-aware query:

fuser -v -u /path/to/file

Confirm that the listed processes are the ones you intend to stop, and assess whether they are writing data, serving clients, or holding a critical mount.

Ask for confirmation and narrow the action

Add -i to request confirmation before signaling:

fuser -k -i /path/to/file

When only writers are a problem, add -w:

fuser -k -i -w /mnt/data

This limits the action to processes with write access. It does not make killing safe by itself; a writer may still be a production service or may have unsaved state.

Prefer a catchable signal when possible

Select a different signal, such as TERM, instead of accepting the SIGKILL default:

fuser -TERM -i /path/to/file

A termination signal gives a cooperative program a chance to close files and shut down. Reinspect the target after the application has had time to exit. Escalate only when the process is understood, a normal stop has failed, and the operational impact is acceptable. Killing all users of a mount can interrupt unrelated services and active data writes.

A narrowly scoped termination sequence

1. Inspect. Run fuser -v -u against the exact file, mount, or socket.
2. Validate ownership. Match each PID to its command, user, and access marker. Check whether the process is supervised and whether stopping it will trigger a restart.
3. Choose the smallest target. Query one file or one mount rather than a broad parent directory when the problem is specific.
4. Request confirmation. Use -i, especially in a shell shared by several administrators.
5. Start with TERM. Use an explicit catchable signal when the application can shut down cleanly.
6. Verify the result. Run the read-only query again and check logs or service status.
7. Use SIGKILL only as a conscious last resort. Document why normal termination was insufficient and what data or service impact was accepted.

Common tasks and the right command

How fuser fits with neighboring tools

fuser is convenient when the question starts with a resource: a path, file system, device, or port. Its output can be terse for shell tests or expanded into a process-oriented view with -v -u. It can also deliver signals to every matching process, which is powerful but raises the risk of an overly broad action.

lsof is another commonly used file-and-socket inspection tool, while ss is commonly used for socket-oriented inspection. Choose among them according to the question, the utilities installed on the system, the detail you need, and the visibility granted to your account. Do not treat one tool’s empty result as proof that another namespace or another user’s process is inactive.

Quick Recap

SaleBestseller No. 1

The Linux Command Line, 3rd Edition: A Complete Introduction

$27.94

Bestseller No. 2

The Linux Command Line, 2nd Edition: A Complete Introduction

$11.34

Bestseller No. 3

Linux Command Line: A Simple Beginner’s Guide to Linux Commands and Terminal Basics

$1.99

SaleBestseller No. 4

Linux Pocket Guide: Essential Commands

$19.75

SaleBestseller No. 5

Linux Command Reference Guide: 500+ Essential Commands and Examples for Everyday Use (Rheinwerk Computing)

$33.91

Troubleshooting an unexpected result

No output for a file you know is open

• Repeat with -v -u so the report is not limited to terse PID output.
• Run the command with the least privilege needed to inspect other users’ descriptors.
• Confirm that the path is the same file and not a replaced pathname, symlink target, or different mount.
• Check whether the process is in another mount namespace.

A port check says “free,” but a service cannot bind

• Query the correct protocol with -n tcp or -n udp.
• Check both address families, or explicitly test with -4 and -6.
• Retry with appropriate privileges because an unprivileged TCP/UDP lookup can miss another user’s socket.
• Verify that the service is attempting the port you queried and not a service name resolving to a different port.

The mount remains busy after a process was stopped

• Run fuser -vmM /mnt/data again rather than relying on the earlier PID list.
• Look for shells whose current directory is inside the mount and for memory-mapped files.
• Include kernel entries by keeping -v enabled.
• Consider processes in a different mount namespace and inspect from the namespace that owns the mount.

You are considering -k because the command is convenient

• Stop and identify the process first.
• Determine whether it is a supervised service, a user session, or a data-writing workload.
• Use -i and a narrow target.
• Try TERM before the default SIGKILL and verify the outcome.

A compact operating checklist

1. State the exact resource: path, device, mount point, TCP port, or UDP port.
2. Run a read-only command with -v; add -u when ownership matters.
3. For mounts, use -m and add -M when the operand must be a real mount point.
4. For sockets, choose the namespace with -n tcp or -n udp; check IPv4 and IPv6 deliberately.
5. If the result is unexpectedly empty, evaluate permissions and mount namespaces before changing the resource.
6. Use -s only when a script needs the exit status rather than display output.
7. Before signaling, narrow the target, confirm the PIDs, and assess data and service impact.
8. Prefer an explicit catchable signal with -i; reserve default SIGKILL for a justified last resort.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.