Pass the Linux Foundation Certified SYSADMIN LFCS Questions and answers with Dumpstech

Step 1: Connect to the correct Linux server.

The video specifies that this task must be performed on host lfcs00073.

From the candidate terminal, execute:

ssh candidate@lfcs00073

This establishes an SSH connection to the designated Linux server.

All subsequent configuration changes must be performed on this host.

Step 2: Verify that user jack exists.

Execute:

id jack

This displays the user's UID, primary group and supplementary groups.

An example of valid output is:

uid=1001(jack) gid=1001(jack) groups=1001(jack)

The numerical IDs may differ.

You can also verify the account through the system user database:

getent passwd jack

The task requires modifying SSH authentication, not creating or modifying the user account.

Do not execute passwd jack or change the user's existing password.

Step 3: Identify the OpenSSH daemon configuration file.

The primary OpenSSH server configuration file on Ubuntu is:

/etc/ssh/sshd_config

Additionally, OpenSSH may load configuration fragments from:

/etc/ssh/sshd_config.d/

Inspect the primary configuration file:

sudo cat /etc/ssh/sshd_config

Check whether additional configuration files exist:

sudo ls -la /etc/ssh/sshd_config.d/

The effective OpenSSH configuration may depend on directives in both locations.

Step 4: Identify the existing authentication settings.

Execute:

sudo grep -RniE \

'KbdInteractiveAuthentication|ChallengeResponseAuthentication|UsePAM|AuthenticationMethods|Match' \

/etc/ssh/sshd_config /etc/ssh/sshd_config.d/ 2 > /dev/null

This searches for authentication-related directives.

The most important directive is:

KbdInteractiveAuthentication

It controls whether the SSH daemon permits keyboard-interactive authentication.

Possible values:

Configuration

Meaning

KbdInteractiveAuthentication yes

Permits keyboard-interactive authentication

KbdInteractiveAuthentication no

Disables keyboard-interactive authentication

On Ubuntu 22.04, the packaged OpenSSH configuration commonly disables keyboard-interactive authentication globally while enabling PAM.

OpenSSH daemon configuration file

However, the task requires the method to be enabled specifically for jack, without changing other users' login ability.

Therefore, simply changing the global directive from no to yes is not the appropriate solution.

Step 5: Examine the effective configuration before changing anything.

Execute:

sudo sshd -T \

-C user=jack,host=localhost,addr=127.0.0.1

This displays the effective SSH daemon configuration for a connection matching user jack.

To filter the relevant settings:

sudo sshd -T \

-C user=jack,host=localhost,addr=127.0.0.1 \

| grep -E 'kbdinteractiveauthentication|usepam|authenticationmethods'

For example, an initial configuration might show:

kbdinteractiveauthentication no

usepam yes

authenticationmethods any

This is an illustrative output. The actual values must be checked on the server.

Also record the same settings for another existing user, such as candidate:

sudo sshd -T \

-C user=candidate,host=localhost,addr=127.0.0.1 \

| grep -E 'kbdinteractiveauthentication|usepam|authenticationmethods'

These baseline values will be useful when verifying that other users remain unaffected.

Step 6: Back up the existing OpenSSH configuration.

Before modifying the daemon configuration, execute:

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

cp copies the configuration file.

-a preserves ownership, permissions and other file metadata.

/etc/ssh/sshd_config.bak is the backup copy.

If a configuration error occurs, the original file can be restored.

Keep the existing SSH session open while making these changes.

Step 7: Edit the OpenSSH daemon configuration.

Open the configuration file:

sudo nano /etc/ssh/sshd_config

Alternatively, use Vim:

sudo vim /etc/ssh/sshd_config

Review any existing Match directives before adding the required configuration.

Step 8: Configure keyboard-interactive authentication specifically for jack.

Provided no earlier matching block takes precedence, append the following configuration at the end of /etc/ssh/sshd_config:

Match User jack

KbdInteractiveAuthentication yes

This is the central configuration required for the task.

Match User jack

The Match directive begins a conditional configuration section.

The User jack condition means that the directives inside this section apply to connections authenticating as jack.

KbdInteractiveAuthentication yes

This enables keyboard-interactive authentication for connections satisfying the preceding Match condition.

Other users do not match User jack, so they retain their existing global or user-specific settings.

OpenSSH's official documentation permits KbdInteractiveAuthentication inside a Match section.

OpenSSH daemon configuration file

Important: If the existing configuration already contains a matching Match User jack or Match All block setting this option, edit the appropriate existing rule instead. OpenSSH generally uses the first occurrence of a directive among satisfied Match blocks. Simply appending a later block may not override an earlier matching rule.

Step 9: Save the configuration file.

If using Nano:

Press Ctrl + O to save.

Press Enter to confirm.

Press Ctrl + X to exit.

If using Vim, press Esc, type :wq, and press Enter.

The modified file should contain the user-specific rule:

Match User jack

KbdInteractiveAuthentication yes

Do not add a global AllowUsers jack rule. That could prevent other users from logging in and would violate the task.

Step 10: Verify the PAM authentication setting.

Execute:

sudo sshd -T \

-C user=jack,host=localhost,addr=127.0.0.1 \

| grep usepam

For the normal Ubuntu PAM-based authentication setup, the expected configuration is:

usepam yes

UsePAM yes allows OpenSSH to use PAM for keyboard-interactive authentication.

On Ubuntu, this directive normally appears in the global configuration.

Do not place UsePAM inside the Match User jack block. It is not a valid Match-specific directive in the relevant OpenSSH configuration.

If PAM is globally disabled, investigate the existing authentication design before changing it. Enabling PAM globally could affect other users, contrary to the task's constraints.

Step 11: Validate the SSH configuration syntax.

Before reloading the daemon, execute:

sudo sshd -t

sshd is the OpenSSH server daemon.

-t validates the configuration and checks relevant server key requirements.

A successful validation normally produces no output and returns exit code 0.

Check the result:

echo $?

Expected:

0

If errors are displayed, correct them before proceeding.

Do not restart or reload SSH with an invalid configuration.

Step 12: Verify that keyboard-interactive authentication is enabled for jack.

Execute:

sudo sshd -T \

-C user=jack,host=localhost,addr=127.0.0.1 \

| grep kbdinteractiveauthentication

Expected output:

kbdinteractiveauthentication yes

This confirms the effective server configuration for the specified user and connection context.

Unlike simply inspecting the configuration file, sshd -T -C evaluates applicable Match rules.

OpenSSH daemon

Step 13: Confirm that other users' authentication settings have not changed.

Execute:

sudo sshd -T \

-C user=candidate,host=localhost,addr=127.0.0.1 \

| grep -E 'kbdinteractiveauthentication|usepam|authenticationmethods'

Compare the output with the baseline recorded in Step 5.

If the original configuration had keyboard-interactive authentication disabled for candidate, it should remain disabled.

For example:

kbdinteractiveauthentication no

usepam yes

authenticationmethods any

The important requirement is that other users retain their original effective authentication settings, not that every server necessarily produces these example values.

Also verify any existing AuthenticationMethods policy. If it requires a method sequence that excludes standalone keyboard-interactive authentication, simply enabling KbdInteractiveAuthentication may not permit a keyboard-interactive-only login. Any necessary adjustment must remain specific to jack.

Step 14: Reload the OpenSSH daemon.

After verifying the configuration, execute:

sudo systemctl reload ssh

On Ubuntu, the systemd service is normally named ssh.

Reloading causes the daemon to apply its updated configuration without unnecessarily terminating established SSH sessions.

Step 15: Verify the SSH service is operational.

Execute:

sudo systemctl status ssh --no-pager

Expected active status:

Active: active (running)

You can also execute:

systemctl is-active ssh

Expected:

active

Step 16: Test keyboard-interactive authentication for jack.

From a separate SSH session, execute:

ssh -o PreferredAuthentications=keyboard-interactive \

-o PubkeyAuthentication=no \

-o PasswordAuthentication=no \

jack@localhost

PreferredAuthentications=keyboard-interactive selects keyboard-interactive authentication.

PubkeyAuthentication=no prevents the client from authenticating using a public key.

PasswordAuthentication=no disables the separate SSH password authentication method, without disabling keyboard-interactive prompts.

jack@localhost attempts to connect as user jack.

If PAM supports the account and the user supplies the correct existing credentials, the server should permit keyboard-interactive authentication.

If the server uses a multi-factor AuthenticationMethods policy, adapt the test to that policy and confirm keyboard-interactive authentication is offered at the appropriate stage.

Do not modify jack's password to perform the test.

Step 17: Perform final configuration checks.

Execute:

sudo sshd -t

Verify the setting for jack:

sudo sshd -T \

-C user=jack,host=localhost,addr=127.0.0.1 \

| grep kbdinteractiveauthentication

Expected:

kbdinteractiveauthentication yes

Verify another user's setting:

sudo sshd -T \

-C user=candidate,host=localhost,addr=127.0.0.1 \

| grep kbdinteractiveauthentication

The value must remain consistent with that user's original configuration.

Finally:

systemctl is-active ssh

Expected:

active

Final Solution

1. Connect to the correct host.

ssh candidate@lfcs00073

2. Back up the SSH configuration.

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

3. Edit the configuration file.

sudo nano /etc/ssh/sshd_config

4. Add the required configuration at the appropriate location, after checking existing Match rules.

Match User jack

KbdInteractiveAuthentication yes

5. Validate the SSH configuration.

sudo sshd -t

6. Verify the effective setting for jack.

sudo sshd -T \

-C user=jack,host=localhost,addr=127.0.0.1 \

| grep kbdinteractiveauthentication

Expected:

kbdinteractiveauthentication yes

7. Reload the SSH daemon.

sudo systemctl reload ssh

8. Confirm that SSH remains active.

systemctl is-active ssh

Expected:

active

Technical Verification and References

The solution has been checked against the official OpenSSH documentation for Ubuntu.

Match User applies specified configuration directives to connections matching a particular username.

KbdInteractiveAuthentication controls whether keyboard-interactive authentication is permitted.

UsePAM enables PAM integration used for keyboard-interactive authentication on typical Ubuntu systems.

sshd -t validates server configuration syntax.

sshd -T -C evaluates effective configuration settings for a particular connection, including applicable Match sections.

Official references:

Ubuntu OpenSSH sshd_config(5)

Ubuntu OpenSSH sshd(8)

OpenSSH Configuration Reference

Expected result: Keyboard-interactive authentication is persistently permitted for user jack, without changing the user's password or altering other users' existing login settings. Successful end-to-end authentication must also be confirmed with a valid login test.

Step 1: Connect to the correct Linux server.

The video specifies that this task must be performed on host lfcs00101a.

From the candidate terminal, execute:

ssh lfcs00101a

This establishes an SSH session with the server where the Apache service is failing.

All subsequent troubleshooting, configuration changes, and service operations must be performed on this host.

Step 2: Check the current status of the Apache service.

Execute:

sudo systemctl status apache2

This is the primary systemd command for checking the status of Apache.

It displays information such as:

Whether the apache2 service is loaded.

Whether the service is running, inactive or failed.

The process ID and execution status.

Recent service log messages.

Errors reported during startup.

An illustrative failure might appear as follows:

× apache2.service - The Apache HTTP Server

Loaded: loaded (/lib/systemd/system/apache2.service; enabled)

Active: failed (Result: exit-code)

Process: 1234 ExecStart=/usr/sbin/apachectl start

Main PID: 1234 (code=exited, status=1/FAILURE)

This is an example, not an output confirmed from the supplied video.

The Active: failed status means the service was unable to complete startup successfully.

Use the actual error messages to determine the cause.

Step 3: Examine the Apache service logs.

Execute:

sudo journalctl -u apache2 -b --no-pager

journalctl displays logs collected by systemd.

-u apache2 filters messages associated with the Apache service.

-b restricts results to the current boot.

--no-pager prints output directly without opening an interactive pager.

To display only the latest 50 messages:

sudo journalctl -u apache2 -n 50 --no-pager

These logs help identify why Apache failed.

Possible causes include:

Incorrect permissions on the Apache executable.

Invalid configuration directives.

Missing configuration files.

Another process using the required network port.

Inaccessible log directories.

Missing modules or other dependencies.

The official systemd documentation supports using journalctl -u to investigate the logs associated with a particular service.

Freedesktop

Step 4: Check the Apache executable.

On Ubuntu, the Apache server executable is normally located at:

/usr/sbin/apache2

Verify its existence:

ls -l /usr/sbin/apache2

For a more detailed permissions check:

stat -c '%A %a %U:%G %n' /usr/sbin/apache2

A correctly installed executable would typically have permissions similar to:

-rwxr-xr-x 755 root:root /usr/sbin/apache2

The x characters represent execute permission.

For example, if the permissions were incorrectly changed to:

-rw-r--r--

the executable would lack execution permission.

This can prevent Apache from starting successfully.

Step 5: Inspect the complete path permissions.

Execute:

namei -l /usr/sbin/apache2

This examines the permission bits and ownership of each directory component leading to the executable.

It helps distinguish between:

A non-executable Apache binary.

A directory that lacks search permission.

Incorrect ownership or permissions elsewhere in the path.

Also verify which package owns the executable:

dpkg -S /usr/sbin/apache2

On Ubuntu, it normally belongs to the apache2-bin package.

If required, check package-file integrity:

sudo dpkg -V apache2-bin

Package verification can help identify unexpectedly modified permissions or file contents.

Step 6: Correct the executable permission if it is the source of the failure.

In the supplied video, the candidate executes:

sudo chmod +x /usr/sbin/apache2

This is an important observation.

The command adds execute permission to the Apache executable according to the applicable chmod rules.

However, the candidate does not visibly demonstrate the earlier diagnostic output proving that missing execute permission caused the failure.

If the executable genuinely lacks its required execute permission, restore its expected mode:

sudo chmod 755 /usr/sbin/apache2

chmod changes file permissions.

755 grants read, write and execute permissions to the owner.

755 grants read and execute permissions to the group.

755 grants read and execute permissions to other users.

This is appropriate for a standard root-owned Apache executable when its mode has been incorrectly changed.

Do not execute this as a universal fix if the actual failure is a configuration error or port conflict.

Step 7: Verify the corrected permissions.

Execute:

ls -l /usr/sbin/apache2

Expected permissions, assuming the standard installation:

-rwxr-xr-x

For numerical verification:

stat -c '%a %n' /usr/sbin/apache2

Expected:

755 /usr/sbin/apache2

If the file's ownership is also incorrect, compare it with the package's expected ownership before making additional changes.

Step 8: Check the Apache configuration syntax.

Execute:

sudo apache2ctl configtest

This checks the Apache configuration for syntax errors.

For a valid configuration, the expected output is:

Syntax OK

The Apache control utility supports the configtest operation specifically for validating configuration syntax.

Apache HTTP Server Version 2.4

If it reports an error, inspect the identified file and line.

For example, an illustrative error might be:

Syntax error on line 42 of /etc/apache2/apache2.conf

Invalid command 'InvalidDirective'

In that case, correct the configuration directive instead of modifying executable permissions.

A successful syntax check does not guarantee that Apache can start, but it eliminates many configuration-related problems.

Step 9: Check whether Apache's required network ports are available.

Apache commonly listens on TCP port 80 for HTTP and port 443 for HTTPS.

Execute:

sudo ss -ltnp

To examine those ports specifically:

sudo ss -ltnp | grep -E ':(80|443)\b'

If another service already occupies a port configured for Apache, startup may fail with an address-binding error.

The official Apache documentation identifies port-binding conflicts as a common startup failure.

Apache HTTP Server Version 2.4

Do not stop another service unless the diagnostic evidence establishes that it is the source of the problem and the change is appropriate.

Step 10: Check Apache's own error log if necessary.

Execute:

sudo tail -n 50 /var/log/apache2/error.log

This displays recent entries from the standard Ubuntu Apache error log.

The file may contain additional details not included in the systemd journal.

Look for permission errors, configuration failures, missing resources or binding errors.

If the executable-permission repair was the only required correction, there may be no additional configuration changes to make.

Step 11: Start the Apache service.

After correcting the identified problem, execute:

sudo systemctl start apache2

sudo provides administrative privileges.

systemctl manages systemd services.

start requests that the specified service begin running.

apache2 identifies the Apache service unit.

This command directly satisfies the task's instruction to start the systemd service.

In the video, the candidate uses:

sudo systemctl restart apache2

The restart operation stops and starts an active service or starts it when appropriate.

Either operation can result in Apache running, but systemctl start apache2 is the more direct choice when the service is currently stopped or failed.

Step 12: Verify that Apache is running.

Execute:

sudo systemctl status apache2

Expected successful status:

● apache2.service - The Apache HTTP Server

Loaded: loaded

Active: active (running)

The critical field is:

Active: active (running)

This indicates that systemd considers the service active.

The official systemctl documentation defines the status command as the way to inspect the current runtime state of a service unit.

Linux manual page

Step 13: Verify the active service state directly.

Execute:

systemctl is-active apache2

Expected output:

active

Check the exit status immediately afterward:

echo $?

Expected:

0

The service is considered active when systemctl is-active returns active with a successful exit status.

Step 14: Verify that Apache is listening for connections.

Execute:

sudo ss -ltnp | grep apache2

This should display Apache processes listening on the ports specified in its configuration, provided those sockets can be associated with the process in the command output.

Alternatively, check the configured HTTP port:

sudo ss -ltnp | grep ':80'

An illustrative successful result might include:

LISTEN 0 511 0.0.0.0:80 0.0.0.0:*

The actual listening address and ports depend on Apache's configuration.

Step 15: Test the Apache HTTP service.

Execute:

curl -I http://localhost

This sends an HTTP HEAD request to the local web server.

An example of a successful HTTP response is:

HTTP/1.1 200 OK

Server: Apache/2.4.x (Ubuntu)

Content-Type: text/html

The exact response code depends on the website's configuration. For example, a redirect or authentication response can still show that Apache is accepting connections.

If the service is active but HTTP requests fail, inspect its listener configuration and logs.

Step 16: Confirm that the service remains running.

Execute:

sleep 5

systemctl is-active apache2

Expected:

active

This additional check helps detect a service that starts briefly and then fails.

You can also inspect recent logs:

sudo journalctl -u apache2 -n 20 --no-pager

Confirm that no further startup or runtime failures have occurred.

Step 17: Perform final verification.

Execute:

sudo apache2ctl configtest

systemctl is-active apache2

sudo systemctl status apache2 --no-pager

curl -I http://localhost

The final requirements are:

Verification

Expected result

Apache configuration test

Syntax OK

Apache executable permission

Valid executable permissions

systemd service status

active (running)

HTTP connectivity

A valid response from the configured service

Original startup failure

Resolved

Final Solution

The video suggests the failure may be related to execute permission on /usr/sbin/apache2. The following is the concise command sequence for that specific confirmed failure.

1. Connect to the server.

ssh lfcs00101a

2. Check the service failure.

sudo systemctl status apache2

sudo journalctl -u apache2 -n 50 --no-pager

3. Inspect the Apache executable permissions.

ls -l /usr/sbin/apache2

4. Restore executable permissions if they are incorrect.

sudo chmod 755 /usr/sbin/apache2

5. Validate the Apache configuration.

sudo apache2ctl configtest

6. Start the Apache service.

sudo systemctl start apache2

7. Verify the running service.

sudo systemctl status apache2

systemctl is-active apache2

Expected:

active

8. Verify HTTP connectivity.

curl -I http://localhost

Technical Verification and References

The procedures are consistent with official Apache and systemd documentation:

Apache HTTP Server — apachectl and configtest

Apache HTTP Server — Startup and Troubleshooting

Linux systemctl — Managing Service Units

systemd journalctl — Service Log Inspection

Expected result: The cause preventing apache2 from starting is corrected, and the service is successfully started with systemd and remains in the active (running) state.

Video verification finding: The candidate visibly runs sudo chmod +x /usr/sbin/apache2 and then attempts to restart Apache. That is a valid repair if missing executable permission was the actual fault, but the visible commands do not independently prove the diagnosis or final service state. The diagnostic and verification steps above are necessary for a reliable solution.

Objective: Identify which Linux block device is experiencing excessive write activity, determine the user process generating that activity, terminate the offending process, and unmount the affected filesystem.

The solution requires four main operations:

Examine block-device read/write statistics.

Identify the process responsible for the heavy disk writes.

Terminate the identified process.

Unmount the filesystem associated with the affected block device.

The video provides useful evidence about the responsible process.

Findings from the video

Required host

lfcs00099

Process generating heavy writes

batches

Observed process ID

891

Process owner

root

Observed write rate Approximately 1,200 KiB/s in one sample

Mountpoint acted on in video

/media/batches

The recording shows batches as the principal writer and the candidate subsequently unmounting /media/batches. However, the original block-device name is not established clearly enough to quote as an exact device path. The solution below includes the commands needed to confirm that mapping.

Step 1: Connect to the correct Linux server.

The video specifies host lfcs00099.

Execute:

ssh lfcs00099

All diagnostic commands, process termination and unmounting must be performed on this host.

Step 2: Examine all available block devices.

Execute:

lsblk

For a more informative output:

lsblk -p -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

Column

Purpose

NAME

Absolute block-device path

TYPE

Disk, partition, or logical device

SIZE

Device capacity

FSTYPE

Filesystem type

MOUNTPOINTS

Where the device's filesystem is mounted

An illustrative output might be:

NAME TYPE SIZE FSTYPE MOUNTPOINTS

/dev/sda disk 40G

└─/dev/sda1 part 40G ext4 /

/dev/sdb disk 10G

└─/dev/sdb1 part 10G ext4 /media/batches

/dev/sdc disk 20G

└─/dev/sdc1 part 20G ext4 /media/data

This output is an example, not confirmed device assignments from the video.

Do not assume that /dev/sdb1 is the affected device until the actual machine's storage configuration is inspected.

Step 3: Identify the block device experiencing excessive writes.

Use iostat, which is part of the sysstat utilities.

Execute:

iostat -dx 1 5

-d displays block-device activity.

-x enables extended I/O statistics.

1 specifies a one-second sampling interval.

5 requests five reports.

The command displays measurements for each block device.

Pay particular attention to:

Metric

Meaning

w/s

Write requests completed per second

wkB/s

Kilobytes written per second

w_await

Average time spent completing write requests

%util

Percentage of elapsed time during which the device had I/O requests

A device with unusually high sustained write throughput compared with the other devices is a candidate for the problematic storage workload.

An illustrative comparison:

Device r/s w/s rkB/s wkB/s %util

sda 2.00 1.00 8.00 4.00 1.00

sdb 0.00 250.00 0.00 1200.00 95.00

sdc 1.00 4.00 4.00 16.00 3.00

In this example, sdb deserves investigation.

High %util by itself does not establish a device fault, especially on modern parallel-I/O storage. Evaluate write throughput, latency and workload together. The official sysstat documentation defines these metrics.

GitHub

Step 4: Identify which user process is causing the write load.

The recording uses iotop to monitor process-level disk activity.

Execute:

sudo iotop

For a view restricted to processes currently performing I/O:

sudo iotop -oP

-o shows processes actively performing I/O.

-P presents process-level information rather than individual threads.

iotop displays process IDs, owners, disk-read rates, disk-write rates and command names.

The important columns are:

TID PRIO USER DISK READ DISK WRITE COMMAND

The task concerns heavy writes, so focus on DISK WRITE, not DISK READ.

The official iotop manual confirms that these measurements represent process-level I/O activity.

Linux manual page

Step 5: Identify the offending process from the video.

At approximately 32:45–33:25 in the recording, the terminal shows iotop output with processes including:

PID USER DISK READ DISK WRITE COMMAND

891 root 0 B/s ~1200 KiB/s batches

927 root ~1200 KiB/s 0 B/s ingest

909 root ~20 KiB/s ~20 KiB/s data

944 root ~20 KiB/s ~20 KiB/s export

These are rounded observations from the displayed sampling interval, not fixed process characteristics.

The important distinction is that ingest is responsible mainly for read activity in the observed samples, whereas batches is the dominant writer.

Therefore, the process to investigate and terminate is batches, observed as PID 891.

PIDs are assigned dynamically and must be checked on the live system before termination.

Step 6: Verify the identity of the process.

On the exam host, execute:

ps -p 891 -o pid,ppid,user,comm,args

For the recorded session, the command should identify batches if PID 891 is still assigned to the same process.

The ps output displays:

PID: process identifier.

PPID: parent process identifier.

USER: account that owns the process.

COMMAND/ARGS: executable name and command-line arguments.

If the PID is different in a fresh session, substitute the PID obtained from iotop.

Do not terminate PID 891 blindly on another system.

Step 7: Verify the process's actual write activity.

Linux exposes per-process I/O statistics through:

/proc/PID/io

For the observed PID:

sudo cat /proc/891/io

The output includes fields such as:

rchar:

wchar:

syscr:

syscw:

read_bytes:

write_bytes:

cancelled_write_bytes:

The write_bytes field reports bytes attributed to the process as writes to the storage layer.

You can inspect the relevant fields:

sudo grep -E 'read_bytes|write_bytes' /proc/891/io

Take two measurements several seconds apart to determine whether write activity is increasing.

The Linux kernel's /proc/PID/io documentation describes these counters and their limitations.

Linux manual page

Step 8: Identify the filesystem being written to by batches.

Execute:

sudo lsof -p 891

lsof lists open files associated with the selected process.

Look for open files located under the affected mountpoint.

For example, paths might begin with:

/media/batches/

If the process has an open writable file on /media/batches, that supports the connection between the observed write activity and this filesystem.

Be aware that lsof lists open resources; not every open file is necessarily responsible for the observed write rate.

Cross-check with block-device I/O measurements.

Step 9: Identify the actual block device mounted at /media/batches.

Execute:

findmnt --mountpoint /media/batches

For concise output:

findmnt -no SOURCE,FSTYPE,TARGET --mountpoint /media/batches

This displays the filesystem source and mountpoint.

For example:

/dev/sdb1 ext4 /media/batches

If this is the output, the block-device path is /dev/sdb1.

This is illustrative. The actual block device must come from the exam host.

Also verify the mapping through:

lsblk -p -o NAME,TYPE,FSTYPE,MOUNTPOINTS

The official findmnt(8) manual documents using --mountpoint to inspect the filesystem mounted at a particular directory.

Linux manual page

Step 10: Confirm that the identified device is responsible for the heavy write activity.

Compare the block device reported by findmnt with the output of:

iostat -dx 1 5

You should now have both pieces of information required by the first part of the task:

The block device experiencing the heavy writes.

The responsible process.

For the recorded scenario, the process evidence points to batches, and the candidate's selected target is /media/batches.

If the block-device statistics instead identify another device, investigate the discrepancy before terminating anything.

Step 11: Check whether the offending process is still running.

Execute:

ps -p 891

Or, using the PID obtained from the current investigation:

ps -p PID -o pid,user,comm,args

Replace PID with the actual current process ID.

Confirm the command name and owner one final time immediately before sending a termination signal.

Step 12: Terminate the process gracefully.

The recommended first attempt is:

sudo kill -TERM 891

This sends SIGTERM to the observed process.

SIGTERM requests an orderly shutdown and allows applications to perform cleanup operations.

Check whether the process has stopped:

ps -p 891

The official Linux kill(1) manual recommends attempting SIGTERM before SIGKILL when possible.

Linux manual page

Step 13: Forcefully terminate the process only if required.

The candidate in the video uses:

sudo kill -9 891

This sends SIGKILL, which terminates the process without allowing it to handle the signal.

The equivalent named-signal command is:

sudo kill -KILL 891

This is technically valid if the process cannot be stopped normally.

However, it is preferable to attempt SIGTERM first, because abruptly killing a writer may interrupt in-progress writes or application cleanup.

For the recorded process, PID 891 is the primary target. The video additionally shows the candidate killing PIDs 909 and 944, but those processes display much lower write activity. Their termination is not justified solely by the task evidence.

Step 14: Verify the offending process has stopped.

Execute:

ps -p 891 -o pid,comm

If the process has fully exited, it should no longer appear as an active process.

You can also inspect:

sudo iotop -oP

The batches process should no longer be generating disk writes.

If the process has restarted automatically with a new PID, investigate its parent process or service rather than relying on the original PID.

Step 15: Inspect remaining users of the affected filesystem.

Before unmounting, execute:

sudo fuser -vm /media/batches

This identifies processes accessing files on the filesystem.

The options mean:

-v: display verbose information.

-m: identify processes accessing the specified mounted filesystem.

The fuser documentation describes this behavior.

Linux manual page

Review the output.

If unrelated processes still need the filesystem, determine whether they can safely stop accessing it. Do not kill every listed process indiscriminately.

Step 16: Unmount the affected filesystem.

Once the offending process has stopped and the filesystem is no longer busy, execute:

sudo umount /media/batches

This is the unmount operation shown in the recording.

sudo provides administrative privileges.

umount detaches a mounted filesystem from the Linux directory hierarchy.

/media/batches identifies the target mountpoint.

The official umount(8) manual confirms that specifying the mountpoint is the normal way to unmount a filesystem.

Linux manual page

Step 17: Handle a busy filesystem if necessary.

If the command reports:

umount: /media/batches: target is busy

it means the filesystem is still being used.

Recheck:

sudo fuser -vm /media/batches

Also inspect:

sudo lsof +f -- /media/batches

A process may have open files, memory mappings, or its working directory on that filesystem.

Close those references appropriately and retry:

sudo umount /media/batches

Do not immediately force or lazily unmount the filesystem.

A lazy unmount can hide an ongoing problem by detaching the mountpoint while references to the filesystem remain. The official umount documentation warns about this distinction.

Linux manual page

Step 18: Verify the filesystem is unmounted.

Execute:

findmnt --mountpoint /media/batches

A successful unmount should result in no matching mount being displayed.

For an additional check:

mountpoint -q /media/batches

echo $?

A nonzero exit status indicates that the directory is not currently a mountpoint.

Also inspect:

lsblk -p -o NAME,TYPE,FSTYPE,MOUNTPOINTS

The affected filesystem should no longer list /media/batches as an active mountpoint.

Step 19: Verify that the excessive write activity has stopped.

Execute:

iostat -dx 1 5

Compare the affected device's write statistics against the measurements recorded before termination.

Also execute:

sudo iotop -oP

Confirm that the original heavy-writing process is no longer active.

Other normal system processes may continue performing I/O. The requirement is to eliminate the problematic workload and unmount its affected device, not to reduce all system writes to zero.

Step 20: Avoid unnecessary modifications to other devices.

The video shows the candidate issuing additional commands involving /media/data and other processes.

Those actions should not automatically be repeated.

The task asks for the block device under heavy write load and the process causing that load.

Unless measurements establish that several devices are affected, there is no reason to unmount unrelated filesystems.

In particular, do not use:

sudo umount -a

This attempts to unmount multiple filesystems and is inappropriate for a targeted storage operation.

Also do not reformat, repartition or remove the affected block device.

Unmounting does not delete the data stored on the filesystem.

Step 21: Consider whether automatic remounting is configured.

Unmounting /media/batches changes the current mounted state, but it does not necessarily prevent the filesystem from being mounted again after a reboot.

For example, the filesystem may be configured through /etc/fstab or a systemd mount unit.

Inspect relevant configuration if the requirement is specifically to keep the device unmounted across restarts:

findmnt --fstab

However, the task instructs you to unmount the device, not explicitly to remove persistent mount configuration.

Do not alter /etc/fstab or disable unrelated services without a demonstrated requirement.

Step 22: Perform final verification.

Execute:

ps -p 891 -o pid,comm

findmnt --mountpoint /media/batches

lsblk -p -o NAME,TYPE,FSTYPE,MOUNTPOINTS

iostat -dx 1 3

If PID 891 is the same offending process observed in the recording and /media/batches is confirmed as its affected filesystem, the expected result is:

Requirement

Expected result

Correct host

lfcs00099

Heavily written block device

Identified using iostat and lsblk

Responsible process

batches

Observed PID

891

Process owner

root

Process terminated

Yes

Affected mountpoint

/media/batches

Filesystem unmounted

Yes

Original excessive write activity

No longer present

Final Solution

The following is the focused command sequence for the scenario shown in the video.

# Connect to the designated server

ssh lfcs00099

# Inspect block devices and mounted filesystems

lsblk -p -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

# Identify the device under heavy write load

iostat -dx 1 5

# Identify the process generating disk writes

sudo iotop -oP

# Confirm the process identity

# Video PID 891; verify the live PID before proceeding

ps -p 891 -o pid,ppid,user,comm,args

# Inspect files opened by the process

sudo lsof -p 891

# Confirm the affected block-device mapping

findmnt -no SOURCE,FSTYPE,TARGET \

--mountpoint /media/batches

# Request orderly termination

sudo kill -TERM 891

# Confirm the process stopped

ps -p 891

# Check remaining filesystem users

sudo fuser -vm /media/batches

# Unmount the affected filesystem

sudo umount /media/batches

# Verify the filesystem is no longer mounted

findmnt --mountpoint /media/batches

# Verify block-device mount status

lsblk -p -o NAME,TYPE,FSTYPE,MOUNTPOINTS

# Check write activity again

iostat -dx 1 3

If normal termination fails and the process is still confirmed to be the same offending workload, use:

sudo kill -KILL 891

Then recheck the process state and retry the unmount.

Technical Verification and References

The procedure has been checked against the following upstream Linux and sysstat documentation:

sysstat iostat Manual

— Measuring block-device I/O activity and write throughput.

Linux iotop(8)

— Identifying processes performing heavy disk I/O.

Linux findmnt(8)

— Identifying filesystem sources and mountpoints.

Linux kill(1)

— Terminating processes using signals.

Linux fuser(1)

— Identifying processes using mounted filesystems.

Linux umount(8)

— Safely detaching filesystems.

Video verification findings

At approximately 32:40–34:15, Question 16 appears on host lfcs00099. The recording shows iotop identifying batches (PID 891, owned by root) as the process producing the dominant write activity.

The candidate then runs:

sudo kill -9 891

sudo umount /media/batches

Both commands are technically valid for their respective operations. However, the recording does not provide a sufficiently clear device-to-mountpoint mapping to certify the actual block-device path. It also shows additional process terminations and unmounts that are not established as necessary by the write measurements.

Expected result: The high-write-load block device is identified, the batches process responsible for the excessive writes is terminated, and its associated filesystem at /media/batches is unmounted after confirming the device mapping. Unrelated processes and storage devices remain unaffected.

next last task now please

Worked for 2m 32s

Step 1: Connect to the correct server.

The video specifies that the task must be completed on host lfcs00082.

From the candidate terminal, connect using:

ssh lfcs00082

This establishes an SSH session with the server where the cron job must be configured.

Step 2: Verify that the user james exists.

Execute:

id james

This displays the user's UID, primary GID, and group memberships.

An example of valid output is:

uid=1001(james) gid=1001(james) groups=1001(james)

The exact numerical IDs may differ. The important requirement is that the user james exists.

Step 3: Verify that the script exists.

Execute:

ls -l /home/james/bin/scanfiles.sh

This verifies the script's location, ownership, and permissions.

You can also check whether james has execute permission:

sudo -u james test -x /home/james/bin/scanfiles.sh

echo $?

An exit status of 0 confirms that the user can execute the script. If the check fails, investigate file and directory permissions.

The task does not require creating or modifying the script.

Step 4: Open the crontab for user james.

Execute:

sudo crontab -u james -e

- sudo provides the privileges needed to manage another user's crontab.

- crontab manages scheduled cron jobs.

- -u james selects the crontab belonging to user james.

- -e opens the selected crontab in a text editor.

This is important because the task explicitly requires scheduling the job for james, not for root or the candidate account.

Step 5: Add the cron job.

Insert the following entry into the crontab:

15 17 * * * /home/james/bin/scanfiles.sh > /home/james/report.txt

This is the exact scheduling command required to satisfy the task.

Step 6: Understand the cron expression.

The cron entry contains five scheduling fields followed by the command.

Field Value Description

Minute 15 Execute at minute 15

Hour 17 Execute at 17:00 (5 PM)

Day of month * Every day of the month

Month * Every month

Day of week * Every day of the week

Therefore, the script executes once daily at 17:15 according to the cron daemon's configured timezone.

The command portion is:

/home/james/bin/scanfiles.sh > /home/james/report.txt

It consists of:

- /home/james/bin/scanfiles.sh — the executable script.

- > — the shell's STDOUT redirection operator.

- /home/james/report.txt — the destination file for standard output.

The > operator creates the report file if it does not exist and the user has permission. If it exists, the output is overwritten on each execution.

Do not replace > with > > because > > appends output. Also, do not use 2 > & 1, because the task requests STDOUT only, not STDERR.

Step 7: Save the crontab.

If the crontab opens in Vim:

1. Press i to enter insert mode.

2. Add the cron entry.

3. Press Esc.

4. Type :wq and press Enter.

If it opens in Nano, press Ctrl+O, Enter, then Ctrl+X.

Once saved, the crontab command installs the updated schedule automatically.

Step 8: Verify the installed cron job.

Execute:

sudo crontab -u james -l

The output must include:

15 17 * * * /home/james/bin/scanfiles.sh > /home/james/report.txt

This verifies that the job is installed under the correct user account.

Step 9: Check the cron service.

On the Ubuntu system shown in the recording, execute:

systemctl status cron

The service should report:

Active: active (running)

If it is inactive, start it:

sudo systemctl start cron

To check whether the service is enabled for startup:

systemctl is-enabled cron

If cron is disabled and must remain operational after reboot, enable it:

sudo systemctl enable cron

Step 10: Verify the final configuration.

Run:

sudo crontab -u james -l

sudo -u james test -x /home/james/bin/scanfiles.sh

systemctl is-active cron

These commands verify that:

1. The required cron entry belongs to james.

2. The script is executable by james.

3. The cron service is active.

The report file is not necessarily present immediately after installing the cron entry. It will be created or overwritten when the scheduled job executes successfully.

Final Solution

The essential command is:

sudo crontab -u james -e

Add:

15 17 * * * /home/james/bin/scanfiles.sh > /home/james/report.txt

Then verify:

sudo crontab -u james -l

Technical verification: This solution follows the documented Linux crontab(1) and crontab(5) syntax. A user-specific crontab executes commands under the owner's account and uses five scheduling fields followed by the command.

Linux manual page

+1

Expected result: The script runs every day at 17:15 as james, directing its standard output to /home/james/report.txt. The schedule's configuration is verified; actual runtime success depends on the script, its permissions, and the target system.

Objective: Configure the Linux NFS (Network File System) server so that two specified client hosts can access the same backup directory with different permissions.

The required configuration is:

NFS client

Required access

Export options

lfcs00098nfs1

Read and write (store backups)

rw,sync,insecure

lfcs00098nfs2

Read-only (restore backups)

ro,sync,insecure

The essential distinction is that the first client must be able to create and modify backup files, while the second client must be restricted to reading existing backup data.

The task explicitly requires the insecure option for both client hosts.

Linux NFS uses /etc/exports to configure which directories are shared, which hosts can access them, and which permissions apply.

Step 1: Connect to the correct Linux server.

The video specifies that this task must be completed on host lfcs00098.

From the candidate terminal, execute:

ssh lfcs00098

This establishes an SSH connection to the designated NFS server.

All NFS export configuration changes must be performed on this server, not on the client hosts.

Step 2: Verify that the NFS server software is installed.

On the Ubuntu environment shown in the video, the NFS server package is normally:

nfs-kernel-server

Check whether the package is installed:

dpkg -l nfs-kernel-server

You can also inspect the service:

systemctl status nfs-kernel-server

If the package is installed and the service is running, continue.

The task is to configure an existing NFS server, so do not reinstall packages unnecessarily.

Step 3: Verify that the backup directory exists.

The task specifies the NFS export directory:

/srv/backup

Execute:

ls -ld /srv/backup

This displays the directory's permissions, owner and group.

For example:

drwxr-xr-x 2 root root 4096 Oct 12 10:00 /srv/backup

The output above is illustrative.

If the directory does not exist, first establish whether the task environment is incomplete. If it is genuinely necessary to create the specified export point, execute:

sudo mkdir -p /srv/backup

Do not modify existing backup files or directory ownership unless needed for authorized client access.

Step 4: Inspect the existing NFS export configuration.

The primary NFS export configuration file is:

/etc/exports

Display its contents:

sudo cat /etc/exports

You can also inspect the configuration using:

sudo nano /etc/exports

The file defines local directories exported to NFS clients.

The general format is:

/directory client1(options) client2(options)

Each client hostname is immediately followed by its own parenthesized options.

There must be no space between the hostname and the opening parenthesis.

This syntax is explicitly documented in the Linux NFS exports(5) manual.

Step 5: Check the currently active NFS exports.

Execute:

sudo exportfs -v

This lists the currently active exports and their effective options.

Check whether /srv/backup is already exported and whether either required client already has an entry.

If an existing configuration is present, modify it carefully rather than creating overlapping or conflicting export entries.

Step 6: Verify that the NFS client hostnames can be resolved.

The task identifies two clients:

lfcs00098nfs1

lfcs00098nfs2

Check name resolution:

getent hosts lfcs00098nfs1

Then:

getent hosts lfcs00098nfs2

These commands query the operating system's configured hostname-resolution services.

Both hostnames should resolve correctly in the exam environment.

Do not replace these hostnames with invented IP addresses.

NFS export configuration supports hostnames, including single hostnames recognized by the system resolver.

Step 7: Back up the existing NFS exports configuration.

Before making changes, execute:

sudo cp -a /etc/exports /etc/exports.bak

This creates a backup copy while preserving file metadata.

It allows recovery if the configuration is accidentally modified incorrectly.

Step 8: Edit the /etc/exports file.

Execute:

sudo nano /etc/exports

Alternatively:

sudo vim /etc/exports

Navigate to the end of the file, or locate the existing export for /srv/backup if one is already present.

Step 9: Configure read/write access for the backup-storage client.

The first requirement is:

First, configure the NFS server to allow access to /srv/backup for host lfcs00098nfs1 to store backups.

The corresponding export configuration is:

/srv/backup lfcs00098nfs1(rw,sync,insecure)

/srv/backup

This is the directory that the NFS server makes available to the specified client.

lfcs00098nfs1

This is the only client identified by this entry.

rw — Read/Write

Allows the NFS client to perform both read and write operations, subject to the underlying filesystem permissions.

This is necessary because the client must store backups.

sync — Synchronous Writes

Makes the NFS server acknowledge write requests only after the relevant changes have been committed to stable storage, as defined by the NFS server's write semantics.

This is appropriate for backup data where durability matters.

insecure — Allow Unprivileged Source Ports

Normally, NFS's secure export behavior requires certain client requests to originate from a privileged port below 1024.

The insecure option relaxes this restriction, permitting requests from unprivileged source ports.

The task explicitly requires this option.

The official NFS manual confirms the behavior of rw, sync and insecure.

Step 10: Configure read-only access for the backup-restore client.

The second requirement is:

Next, configure the NFS server to allow access to /srv/backup for host lfcs00098nfs2 to restore backups only.

The corresponding configuration is:

/srv/backup lfcs00098nfs2(ro,sync,insecure)

lfcs00098nfs2

Specifies the second authorized NFS client.

ro — Read Only

Allows the client to read existing backup files but prevents writes through the NFS export.

This matches the requirement to restore backups only.

sync

Specifies synchronous server behavior. It is safe to include this option even though the export is read-only.

insecure

Allows requests from unprivileged client source ports, as explicitly requested.

The most important difference between the two client definitions is:

lfcs00098nfs1(rw,sync,insecure)

lfcs00098nfs2(ro,sync,insecure)

The second client must not be given rw access.

Step 11: Add the complete NFS export configuration.

The preferred combined entry in /etc/exports is:

/srv/backup lfcs00098nfs1(rw,sync,insecure) lfcs00098nfs2(ro,sync,insecure)

This single line defines the same exported directory with separate permissions for the two clients.

The configuration can also be expressed as two client-specific entries, provided the resulting export table is valid and does not contain conflicting definitions.

Using one line is concise and follows the official exports(5) syntax for multiple clients sharing an export path.

NFS server export table

Step 12: Save the NFS configuration file.

If using Nano, press Ctrl+O, Enter and Ctrl+X.

If using Vim, press Esc, type :wq, and press Enter.

Verify the saved configuration:

sudo cat /etc/exports

The file must contain:

/srv/backup lfcs00098nfs1(rw,sync,insecure) lfcs00098nfs2(ro,sync,insecure)

Preserve any unrelated exports already present on the system.

Step 13: Apply the NFS export configuration.

Execute:

sudo exportfs -ra

exportfs manages the NFS export table.

-r refreshes the export table from the configuration.

-a applies the operation to all configured exports.

This command reloads export definitions without requiring a complete operating system reboot.

For verbose output, you can execute:

sudo exportfs -rav

Ubuntu's official NFS server documentation and the Linux NFS manual describe using exportfs to apply changes made to /etc/exports.

Step 14: Verify the active NFS export configuration.

Execute:

sudo exportfs -v

The output should show /srv/backup exported to both client hosts.

The effective configuration must include the following permissions:

Client

Required effective access

lfcs00098nfs1

rw,insecure

lfcs00098nfs2

ro,insecure

The command may also display other default export options such as root_squash, wdelay, sec=sys, or no_subtree_check, depending on the installed version and configuration.

Their presence does not necessarily indicate an error.

What matters is that the two specified clients have the correct effective access and the required insecure option.

Step 15: Check the NFS server service.

Execute:

sudo systemctl status nfs-kernel-server

The service should report an active operating state.

For a concise check:

systemctl is-active nfs-kernel-server

Expected:

active

If the service is inactive, inspect the logs:

sudo journalctl -u nfs-kernel-server -n 50 --no-pager

If the service is installed and configured correctly but stopped, start it:

sudo systemctl start nfs-kernel-server

There is ordinarily no need to restart a healthy NFS server merely because export rules changed; exportfs -ra is designed to refresh the export table.

Step 16: Verify the backup directory permissions.

Execute:

ls -ld /srv/backup

NFS export permissions and Unix filesystem permissions are separate controls.

Even if lfcs00098nfs1 has an export configured with rw, its application user must also have the necessary filesystem permissions to write to the directory.

Likewise, ro at the export level prevents NFS writes from lfcs00098nfs2, regardless of permissive underlying file permissions.

Do not automatically execute:

sudo chmod 777 /srv/backup

This would unnecessarily grant broad filesystem access.

Also avoid adding:

no_root_squash

unless explicitly required.

The task does not request disabling NFS root squashing, and doing so could expose unnecessary privileges to clients.

Step 17: Verify NFS access from the backup-storage client.

If the client is accessible, connect to:

ssh lfcs00098nfs1

Create a temporary mountpoint:

sudo mkdir -p /mnt/lfcs-backup-test

Mount the NFS export, using the actual NFS server hostname and a protocol version supported by the server:

sudo mount -t nfs lfcs00098:/srv/backup /mnt/lfcs-backup-test

Verify the mount:

findmnt /mnt/lfcs-backup-test

Using a client identity authorized to write to the backup directory, test file creation:

touch /mnt/lfcs-backup-test/lfcs-write-test

If the directory permissions permit this identity to write, the command should succeed.

This tests the read/write access requested for lfcs00098nfs1.

Root access from the client may be mapped to an unprivileged user because of NFS root squashing, so a failure when using root does not automatically mean that the export is configured incorrectly.

Step 18: Verify read-only access from the restore client.

Connect to:

ssh lfcs00098nfs2

Create a mountpoint if necessary:

sudo mkdir -p /mnt/lfcs-backup-test

Mount the export:

sudo mount -t nfs lfcs00098:/srv/backup /mnt/lfcs-backup-test

Verify that backup files can be listed and read:

ls -la /mnt/lfcs-backup-test

Where a readable file is available, open or inspect it using a suitable command.

Next, attempt to create a temporary file:

touch /mnt/lfcs-backup-test/lfcs-readonly-test

This operation must fail because the export is read-only.

An illustrative error is:

Read-only file system

Even if the error wording differs, the important result is that write access is denied by the server.

Step 19: Clean up any test resources.

On the writing client, remove only the temporary verification file you created:

rm -f /mnt/lfcs-backup-test/lfcs-write-test

Unmount the temporary client mount:

sudo umount /mnt/lfcs-backup-test

Repeat the unmount on the other client.

Do not delete or alter actual backup files.

Step 20: Perform final verification on the NFS server.

Reconnect to the NFS server:

ssh lfcs00098

Verify the persistent configuration:

sudo grep '/srv/backup' /etc/exports

Expected:

/srv/backup lfcs00098nfs1(rw,sync,insecure) lfcs00098nfs2(ro,sync,insecure)

Verify the active exports:

sudo exportfs -v

Confirm NFS service health:

systemctl is-active nfs-kernel-server

The final state must satisfy every requirement.

Requirement

Expected result

Exported directory

/srv/backup

Backup-storage client

lfcs00098nfs1

Backup-storage access

Read/write

Backup-restore client

lfcs00098nfs2

Backup-restore access

Read-only

insecure for first client

Present

insecure for second client

Present

Active exports

Correctly refreshed

NFS service

Active

Final Solution

The essential server-side commands are:

# Connect to the NFS server

ssh lfcs00098

# Check the export directory

ls -ld /srv/backup

# Examine existing exports

sudo cat /etc/exports

sudo exportfs -v

# Back up the configuration

sudo cp -a /etc/exports /etc/exports.bak

# Edit the exports file

sudo nano /etc/exports

Add or update the /srv/backup entry to read:

/srv/backup lfcs00098nfs1(rw,sync,insecure) lfcs00098nfs2(ro,sync,insecure)

Save and execute:

# Apply changes

sudo exportfs -ra

# Verify active exports

sudo exportfs -v

# Confirm NFS service status

systemctl is-active nfs-kernel-server

# Verify persistent configuration

sudo grep '/srv/backup' /etc/exports

Technical Verification and References

The solution has been checked against the official Linux NFS manuals and Ubuntu Server documentation.

Linux NFS exports(5) — Defines the export configuration syntax, rw, ro, sync and insecure options.

Ubuntu Server — Network File System (NFS) — Documents the NFS server configuration and export-management procedure.

Linux exportfs(8) — Documents reloading, managing and displaying active exports.

Video verification finding: Task 10 identifies the NFS server lfcs00098 and requires separate access modes for lfcs00098nfs1 and lfcs00098nfs2. The essential answer is the NFS export configuration above. Actual client access must be tested on the relevant systems; correct syntax alone does not establish that network connectivity and filesystem permissions are functioning.

Expected result: The NFS server exports /srv/backup to lfcs00098nfs1 with read/write access and to lfcs00098nfs2 with read-only access. Both client configurations explicitly include insecure, and the settings remain persistent in /etc/exports.