Build Your Own Network File Server — Give Your Raspberry Pi a Job That Is Actually Useful
A Raspberry Pi is often introduced as a small computer for learning Python, experimenting with electronics or perhaps running a simple web server.
But it can do something much more ordinary — and surprisingly useful.
It can become your own network file server.
Instead of keeping a document on one computer, photographs on another and coursework on a USB memory stick that you cannot quite remember where you left, you can create a central storage location that several computers can access across your network.
Better still, we can build it using Linux and then access the files from a Windows PC.
That introduces several important Computer Science ideas at once:
client-server computing;
network protocols;
IP addresses;
file systems;
authentication;
permissions;
network shares;
persistent services;
interoperability between different operating systems.
And unlike some classroom networking exercises, at the end you have built something you might genuinely continue using.
What Exactly Is a File Server?
Imagine I have several computers in my tuition and media environment.
One might contain teaching resources. Another might be used for video editing. A laptop might be used elsewhere in the house.
Without a server, I could copy files between them using USB drives or cloud storage.
That works — but there is another approach.
Put the files in one central location and allow the other computers to request them across the network.
The machine containing the files is the server.
The machines accessing them are clients.
Conceptually:
Windows PC → network → Linux server → storage
The important point is that the server does not necessarily have to be a huge machine in a data centre.
For a home network, classroom or small organisation, a Raspberry Pi can perform the same fundamental role.
That is an excellent demonstration of an important idea:
"Server" describes a role, not necessarily a particular type of computer.
A Raspberry Pi can be a client one moment and provide a server service the next.
Why Not Just Use Google Drive or OneDrive?
That is a perfectly reasonable question.
Cloud storage is enormously convenient, but building our own server allows us to investigate what is actually happening underneath the convenient interface.
It also creates an interesting distinction.
With a local file server:
PC → local network → server
With cloud storage, conceptually:
PC → router → Internet → remote data centre
The cloud system provides many additional services, of course, including synchronisation, remote access, redundancy and often version history.
But our small server gives us control.
It also gives students something perhaps even more valuable:
something they can break, investigate and repair.
That is often where the best Computer Science learning occurs.
Enter Samba
There is one immediate complication.
Our server is running Linux while many of the computers accessing it may run Windows.
They need a common way of communicating.
This is where Samba comes in.
Samba is free software that implements the SMB networking protocol used for file and printer sharing.
SMB stands for Server Message Block.
It allows a Linux machine to provide shared folders that Windows machines can access much like folders hosted by another Windows computer.
This is an excellent example of interoperability.
Two computers do not need to run the same operating system.
They need to agree on the protocol.
That principle extends far beyond file servers.
The web works because browsers and web servers agree on protocols such as HTTP and HTTPS.
Email systems use agreed protocols.
SSH allows remote access between many different systems.
Networking depends heavily upon standardisation.
What You Will Need
This project can be completed with:
a Raspberry Pi or another Linux computer;
Raspberry Pi OS, Ubuntu or a similar Linux distribution;
a connection to your local network;
a Windows PC;
some storage space.
For experimentation, the Pi's existing storage may be adequate.
For a server you intend to use seriously, however, I would normally add an external SSD or other suitable storage device rather than treating a microSD card as a long-term file archive.
Before beginning, update the Linux system:
sudo apt update
and then:
sudo apt upgrade
This is good practice before installing additional software.
Step 1 — Install Samba
On a Debian-based Linux system such as Raspberry Pi OS or Ubuntu, Samba can normally be installed with:
sudo apt install samba
Something important has just happened.
We have not merely installed an application that we open when required.
We have installed software capable of running as a service.
A server needs to sit quietly in the background waiting for clients to make requests.
That distinction between an ordinary application and a continuously available service is worth discussing with Computer Science students.
Step 2 — Create Somewhere to Store the Files
Suppose I want to create a folder called:
SharedFiles
In my home directory I might create it with:
mkdir ~/SharedFiles
I could now place some test files inside it.
For example:
a PDF;
a photograph;
a text document;
a spreadsheet.
At this point they are simply ordinary Linux files.
Windows cannot magically see them just because the computers are connected to the same network.
We must explicitly tell Samba that this directory is to be shared.
Step 3 — Configure the Share
Samba's main configuration file is normally:
/etc/samba/smb.conf
Before altering an important configuration file, I strongly recommend making a backup.
For example:
sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.backup
That is a small habit worth developing.
If our configuration goes badly wrong, we have somewhere to return to.
We can then edit the file using an editor such as nano:
sudo nano /etc/samba/smb.conf
Near the bottom we could add a section along these lines:
[SharedFiles]
path = /home/yourusername/SharedFiles
browseable = yes
read only = no
create mask = 0664
directory mask = 0775
Replace yourusername with the actual Linux username and ensure the path matches the folder you created.
What have we done?
We have given the network share a name — SharedFiles — and told Samba where the actual files are stored.
We have also specified some of its behaviour.
Already we are seeing an important server principle:
the name a client sees does not necessarily reveal exactly how the server stores the resource internally.
Step 4 — Users, Passwords and Permissions
Now things become more interesting.
Should anybody connected to your network be able to alter your files?
Probably not.
We therefore need to think about authentication and authorisation.
These words are sometimes confused.
Authentication: Who are you?
Authorisation: What are you allowed to do?
That distinction is extremely important in Computer Science and cybersecurity.
A Samba user can be given a password with:
sudo smbpasswd -a yourusername
You will be asked to create a Samba password.
The precise permissions you choose depend on what you want the server to do.
For a controlled home server, authenticated access is normally preferable to making folders openly writable by everyone on the network.
This also creates an opportunity to investigate Linux file permissions.
For example:
ls -l
will display file ownership and permissions.
Students can then explore what read, write and execute actually mean for files and directories.
Step 5 — Check the Configuration
Before restarting services, it is sensible to check the Samba configuration:
testparm
This is one of those small commands that teaches a much larger lesson.
Validate a configuration before relying upon it.
If an error has slipped into the file, it is much better to discover it here than spend half an hour wondering why Windows cannot connect.
Step 6 — Restart Samba
After changing the configuration, restart the relevant Samba service. On many Debian-based installations this can be done with:
sudo systemctl restart smbd
We can check its state with:
sudo systemctl status smbd
Now our Linux machine should be waiting for SMB connections.
But our Windows computer still needs to know where to find it.
Step 7 — Find the Server's IP Address
On the Linux machine try:
hostname -I
You may see something such as:
192.168.1.42
The exact number will depend upon your network.
This is the Pi's address on the local network.
Notice what we now have.
Server IP address: identifies the machine.
SMB: defines how file-sharing communication takes place.
Share name: identifies the resource being offered.
Username/password: identifies and authenticates the user.
Several Computer Science concepts that can appear rather abstract on a specification have suddenly become parts of one working system.
Step 8 — Move to Windows
Now go to the Windows computer.
Open File Explorer and enter something like:
\\192.168.1.42\SharedFiles
Replace the IP address with the address of your own server.
Windows should ask for credentials if the share requires them.
Enter the appropriate Samba username and password.
And then comes the satisfying part.
A folder stored on a Linux computer appears inside Windows File Explorer.
Try copying a small test file into it.
Return to the Pi and look inside:
~/SharedFiles
The file should be there.
You have just transferred data from Windows to Linux using a network file-sharing protocol.
Make It Feel Like Another Drive
Windows can go one step further.
Instead of entering the server address every time, the share can be mapped as a network drive.
In File Explorer, choose the option to map a network drive and assign it a drive letter.
You might choose something such as:
S:
The Samba share can then appear alongside the computer's local drives.
To the person using the computer it begins to feel almost like another disk installed in the machine.
But physically the files might be several rooms away.
That separation between a resource's logical appearance and its physical location is another powerful computing concept.
An Experiment: What Happens If the Network Disappears?
Now deliberately disconnect the Pi from the network.
Try opening the mapped drive again.
It fails.
Why?
The files have not disappeared.
The storage device has not failed.
Windows simply cannot reach the machine providing the service.
Reconnect it.
The resource becomes available again.
This simple experiment demonstrates an important weakness of centralised network services:
availability depends upon both the server and the network path to it.
A Better Experiment — Measure File Transfer Speed
We can turn this project into a quantitative investigation.
Choose a reasonably large file — perhaps a 1 GB video file.
Measure how long it takes to transfer.
Transfer rate can be estimated using:
transfer rate = file size / transfer time
Suppose a 1,000 MB file takes 20 seconds.
Then:
transfer rate = 1000 / 20 = 50 MB/s
Be careful with units.
Network speeds are often quoted in bits per second, while file transfer software may report bytes per second.
Since:
1 byte = 8 bits
then:
50 MB/s = approximately 400 Mb/s
ignoring some of the complications of prefixes and protocol overhead.
Now compare:
Wi-Fi versus Ethernet;
small files versus one large file;
one client versus several clients;
Raspberry Pi storage versus an external SSD.
Suddenly the project has become an experiment in network performance.
Why Won't I Get the Advertised Network Speed?
Suppose you are using Gigabit Ethernet.
That suggests a theoretical maximum of:
1 Gbit/s
or roughly:
125 MB/s
Does that mean your 1 GB file will necessarily transfer at 125 MB/s?
No.
There are numerous potential bottlenecks:
storage read speed;
storage write speed;
network protocol overhead;
other network traffic;
processor performance;
Wi-Fi conditions;
cable and switch capability;
SMB configuration.
This leads to a useful engineering principle:
The performance of a system is often determined by its bottleneck rather than its fastest component.
Give the Server a Permanent Address
There is another problem worth discovering naturally.
Today the Pi might be:
192.168.1.42
After a restart or after its DHCP lease changes, it could potentially receive a different address.
Our Windows shortcut might then stop working.
This introduces DHCP.
A DHCP server — commonly your router on a home network — automatically allocates network configuration to devices.
For a machine providing a permanent service, however, a predictable address is useful.
One solution is to create a DHCP reservation in the router so that the Pi normally receives the same IP address.
This is another excellent example of why practical work improves understanding.
Students are no longer learning DHCP simply because it appears in a networking topic.
They have discovered a reason for needing to understand it.
What About Backups?
This is where I would add one very important warning.
A file server is not automatically a backup.
If every important document exists only on the server, there is still only one copy.
If the drive fails, those files may be lost.
If files are accidentally deleted, they may be lost.
If malicious software encrypts files that the client can access, the network copy may also be affected.
A sensible system therefore needs a separate backup strategy.
This is a valuable distinction:
Centralised storage improves organisation and access. Backup improves resilience against data loss.
They are related, but they are not the same thing.
Could We Access It Across the Internet?
Technically, yes — but this is where I would stop treating the exercise as a simple file-sharing project.
I would not simply expose SMB directly to the public Internet.
Remote access introduces a much larger security problem.
A safer future project would investigate technologies such as a VPN, allowing an authorised remote device to connect securely to the home network before accessing internal services.
That leads naturally into:
encryption;
tunnelling;
authentication;
firewalls;
attack surfaces;
remote access security.
One project creates the questions for the next.
Why This Is Particularly Useful for A Level Computer Science
For OCR A Level Computer Science H446 students, the value of this exercise goes well beyond learning how to install Samba.
Consider how many specification ideas we have encountered:
Client-server networking
Windows requests a resource from the Linux server.
Protocols
SMB defines how the systems communicate.
IP addressing
The client needs to locate the server.
DHCP
Addresses may be allocated automatically.
Authentication
Users prove who they are.
Access rights
Different users can be permitted different actions.
Operating systems
Linux and Windows manage their files differently but can communicate through agreed standards.
Secondary storage
The choice of storage hardware affects performance and reliability.
Network performance
Bandwidth and bottlenecks affect transfer speeds.
Cybersecurity
A useful service also creates something that needs protecting.
These are no longer disconnected definitions in revision notes.
They are components of something the student has actually built.
Extensions — Turn One File Server Into a Proper Investigation
Once the basic server works, don't stop.
Try creating two shared directories:
Students
and
Teachers
Could they have different permissions?
Could one user have read-only access?
Could another have permission to modify files?
Try creating several Samba users.
What happens when two computers access the same server simultaneously?
Measure file-transfer speeds.
Monitor processor usage during a large transfer.
Compare Ethernet with Wi-Fi.
Attach an SSD.
Investigate RAID — while being very careful not to confuse RAID with backup.
Add automated backups.
Monitor available disk space.
Create logs.
Try accessing the server remotely using SSH while another computer accesses its files through Samba.
At this point the Raspberry Pi is becoming something much more interesting.
It is becoming a small laboratory for learning how real networked computer systems work.
The Bigger Lesson — Computers Do Not Have to Look Like Computers
There is something I particularly like about projects such as this.
Once configured, the Raspberry Pi does not need a monitor, keyboard or mouse.
It can sit on a shelf.
We might administer it using SSH.
Windows computers access it through Samba.
Most of the time nobody needs to physically touch it.
Yet it is still doing useful computing continuously.
That begins to change our perception of what a computer is.
Computers do not always sit on desks displaying graphical interfaces.
They can quietly provide services.
They can store files.
Host websites.
Run databases.
Control equipment.
Collect sensor data.
Stream media.
Manage networks.
That is why I think learning a little Linux is so valuable for Computer Science students.
It opens the door to a side of computing that is largely invisible when our experience is restricted to opening applications on a Windows PC.
Conclusion — Build It, Break It, Understand It
Installing Samba and sharing a folder is not, by itself, particularly revolutionary.
The real educational value comes from everything that happens around it.
Why does the client need an IP address?
Why does the server need authentication?
Why might permissions prevent a file being written?
Why does changing from Wi-Fi to Ethernet alter performance?
Why might the server's address change?
Why isn't a server automatically a backup?
Why can Windows communicate with Linux at all?
Those questions take us straight into the heart of Computer Science.
And perhaps the most valuable moment comes when something does not work.
Instead of immediately searching for a different piece of software, investigate.
Check the IP address.
Check the service.
Check the configuration.
Check the permissions.
Check the network.
Read the error message.
Build it. Break it. Diagnose it. Fix it.
That is how a £50 computer on a shelf can become a surprisingly powerful Computer Science laboratory.
Practical Challenge
If you have a Raspberry Pi or spare Linux computer, see how far you can take the project:
Level 1: Share one folder with Windows.
Level 2: Require a username and password.
Level 3: Map the share as a Windows network drive.
Level 4: Create users with different permissions.
Level 5: Measure transfer performance over Wi-Fi and Ethernet.
Level 6: Add external storage and a genuine backup system.
Level 7: Explain the whole system using the vocabulary of the OCR Computer Science specification.
If you can reach Level 7, you have moved well beyond simply memorising what a file server is.
You understand why it works.
