CresignSys Learn

CresignSys Learn — Lesson 034

Written by

cresignsys

in

Linux Filesystem — From / to Your WordPress public/

We now move from memory and processes to storage.

The central question is:

When you type /storage/websites/templates.cresignsys.com/public/, what does that actually mean inside Linux?

1. Storage vs Filesystem

First, separate these two concepts.

Storage

Physical or virtual persistent storage:

SSD / NVMe / Cloud Block Volume

Filesystem

The structure Linux uses to organize data on that storage:

/
├── etc
├── var
├── home
├── storage
└── ...

So:

Storage
   ↓
Filesystem
   ↓
Directories
   ↓
Files

2. Linux Has One Main Directory Tree

Linux does not normally present disks to applications as:

C:
D:
E:

as Windows commonly does.

Instead, Linux builds a unified hierarchy starting at:

/

This is called the:

Root directory

3. / Is Not the Same as root

This distinction is important.

/

means:

Root directory

while:

root

usually refers to:

The superuser account

So:

/

and:

/root

are completely different things.

4. Basic Linux Filesystem

A typical Ubuntu server contains directories such as:

/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin
├── srv
├── sys
├── tmp
├── usr
├── var
└── ...

Your server may also have:

/storage

if you created or mounted it.

5. Think of / as the Beginning

When you write:

/storage

Linux interprets it as:

/
 ↓
storage

When you write:

/storage/websites

it means:

/
 ↓
storage
 ↓
websites

6. Your Website Path

Your hosting architecture uses paths such as:

/storage/websites/templates.cresignsys.com/public/

Break it apart:

/
└── storage
    └── websites
        └── templates.cresignsys.com
            └── public

7. What Is a Directory?

A directory is a filesystem object that organizes references to files and other directories.

Conceptually:

Directory
 ├── file
 ├── file
 └── directory

It is better to think of a directory as a namespace/container rather than simply “a folder.”

8. Absolute Path

This is an:

Absolute path

/storage/websites/templates.cresignsys.com/public/

It starts at:

/

and therefore doesn’t depend on your current directory.

9. Relative Path

Suppose you’re currently inside:

/storage/websites/

and run:

cd templates.cresignsys.com

This is a:

Relative path

It means:

current directory
+
templates.cresignsys.com

10. Current Directory

Linux remembers your current working directory.

Run:

pwd

Example:

/storage/websites/templates.cresignsys.com/public

pwd means:

Print Working Directory

11. cd

Move between directories:

cd /storage/websites

Then:

pwd

might show:

/storage/websites

12. ls

List directory contents:

ls

More useful:

ls -la

This shows hidden files and detailed information.

13. .

The symbol:

.

means:

Current directory

For example:

ls .

means:

List the current directory.

14. ..

The symbol:

..

means:

Parent directory

If you are here:

/storage/websites/

then:

cd ..

moves to:

/storage/

15. ~

The symbol:

~

usually means the current user’s home directory.

For user:

ubuntu

it might represent:

/home/ubuntu

16. /root

This is typically the home directory of the root user:

/root

It is not the filesystem root.

Again:

/
    = filesystem root

/root
    = root user's home directory

17. /home

Normal user home directories commonly live here:

/home/ubuntu
/home/user1
/home/user2

18. /etc

This is one of the most important directories for server administration.

It contains configuration.

For example:

/etc/nginx/
/etc/ssh/
/etc/mysql/
/etc/php/

Your Nginx configuration is under:

/etc/nginx/

19. /var

/var contains data that changes during system operation.

Important examples:

/var/log
/var/lib
/var/cache

20. /var/log

Logs are critical when troubleshooting.

For example:

/var/log/nginx/

may contain Nginx logs.

You may also encounter:

/var/log/syslog

and other service logs depending on the system.

21. /var/lib

This commonly contains persistent application state.

For example, database software may store data under paths beneath:

/var/lib/

The exact MySQL/MariaDB path depends on your installation.

22. /run

/run contains runtime state created during boot and service operation.

For example:

/run/php/

may contain PHP-FPM sockets.

23. /tmp

Temporary files commonly live here.

/tmp

Applications can use it for temporary data.

You should not assume files there are permanent.

24. /usr

/usr contains a large part of the operating system’s user-space programs, libraries, documentation, and related files.

For example:

/usr/bin
/usr/sbin
/usr/lib

25. /bin and /sbin

Modern Ubuntu versions use a merged filesystem layout in which directories such as:

/bin
/sbin

may be symbolic links into:

/usr/bin
/usr/sbin

So don’t assume these are physically separate storage areas.

26. /dev

/dev provides interfaces to devices.

Examples include:

/dev/null
/dev/random
/dev/sda

depending on the system.

It is another special filesystem area.

27. /proc

We encountered this in the previous lesson.

/proc

provides kernel/process information.

Example:

cat /proc/meminfo

28. /sys

/sys

provides information and interfaces related to devices, drivers, and the kernel’s device model.

It is another virtual/special filesystem.

29. /dev, /proc, /sys

These are different from ordinary directories containing ordinary files.

Conceptually:

/dev
 ↓
Devices

/proc
 ↓
Processes + kernel information

/sys
 ↓
Devices + kernel subsystem information

30. /storage

Now we reach your hosting architecture.

You have been using:

/storage/websites/

This may be:

a normal directory

or:

a mounted filesystem

depending on how your VPS storage was configured.

We need to determine which.

31. What Is a Mount?

A filesystem can be attached to a directory called a:

Mount point

Conceptually:

Storage device/filesystem
          ↓
      mount point
          ↓
       /storage

After mounting, the contents of that filesystem become accessible through:

/storage

32. Example

Imagine a separate volume:

/dev/sdb

containing a filesystem.

You can mount it at:

/storage

Then:

/dev/sdb
   ↓
mount
   ↓
/storage

Applications access it through the path:

/storage/...

33. Why Mounts Are Useful for Hosting

Suppose your OS disk contains:

/

and you have a separate large volume for websites:

/storage

Then you can keep website data separate from much of the operating system.

Conceptually:

OS storage
   ↓
/

Website storage
   ↓
/storage

This can simplify capacity management and recovery, depending on the infrastructure.

34. How to Check Mounts

Run:

df -h

You may see something like:

Filesystem      Size  Used Avail Use% Mounted on
/dev/...        ...   ...  ...   ...  /
/dev/...        ...   ...  ...   ...  /storage

The exact device names depend on your server.

35. findmnt

A very useful command:

findmnt

This shows mounted filesystems and their mount points.

For just /storage:

findmnt /storage

This can tell you whether /storage is a separate mounted filesystem.

36. lsblk

Another important command:

lsblk

This shows block devices and their relationships.

Conceptually:

disk
├── partition
└── partition

You may see:

nvme0n1
├── nvme0n1p1
└── nvme0n1p2

The actual layout varies by cloud image/provider.

37. Block Device

A block device provides storage in blocks.

Examples:

/dev/sda
/dev/sdb
/dev/nvme0n1

depending on the hardware/virtualization environment.

The filesystem sits on top of the block storage.

38. Storage Stack

A simplified stack is:

Application
    ↓
Filesystem
    ↓
Block device
    ↓
Virtual/cloud storage
    ↓
Physical storage infrastructure

For example:

Nginx
 ↓
ext4 filesystem
 ↓
virtual disk
 ↓
cloud block volume

The exact filesystem and device type must be checked on your VPS.

39. Filesystem Types

Common Linux filesystems include:

ext4
XFS
Btrfs

Your Ubuntu server may commonly use:

ext4

but don’t assume it.

Check with:

df -T

or:

findmnt -T /storage

40. Inode

Now we reach a deeper filesystem concept.

A filesystem doesn’t simply store:

filename → data

It maintains metadata structures.

One important structure is the:

inode

An inode stores metadata about a filesystem object, such as:

File type
Permissions
Owner
Group
Size
Timestamps
References to data blocks

The exact details depend on the filesystem.

41. Filename vs Inode

Conceptually:

Directory
   │
   ├── index.php ─────→ inode
   │
   └── style.css ─────→ inode

The directory associates names with filesystem objects.

The inode contains metadata and references associated with the object.

42. Why Inodes Matter

A filesystem can have:

plenty of disk space

but still run out of:

inodes

if it contains enormous numbers of small files.

Then you can encounter problems creating new files even when:

df -h

shows free space.

43. Check Inode Usage

Run:

df -i

This displays inode usage.

This is particularly relevant to hosting servers containing:

WordPress
cache files
mail
logs
temporary files
many websites

44. File Data Blocks

The actual file contents are stored through filesystem data structures that ultimately reference storage blocks.

Conceptually:

Filename
   ↓
Directory entry
   ↓
inode
   ↓
data blocks
   ↓
storage

This is simplified but gives the right mental model.

45. Why a 1 MB File Isn’t “One Block”

Storage filesystems divide storage into blocks.

For example, a filesystem may use a block size such as:

4096 bytes

A larger file therefore occupies multiple blocks.

Modern filesystems have many optimizations beyond this simple picture.

46. Your WordPress Directory

Now:

/storage/websites/templates.cresignsys.com/public/

might contain:

index.php
wp-admin/
wp-content/
wp-includes/
wp-config.php
.htaccess
...

depending on your installation.

47. WordPress Core

Typical directories:

wp-admin/
wp-includes/
wp-content/

and core files such as:

index.php
wp-load.php
wp-blog-header.php
wp-settings.php

48. wp-content

This is particularly important.

It commonly contains:

wp-content/
├── plugins/
├── themes/
└── uploads/

These are application data/code areas used by WordPress.

49. Plugins

For example:

wp-content/plugins/

contains plugin directories.

A plugin can contain:

PHP
CSS
JavaScript
Images
Other resources

50. Themes

wp-content/themes/

contains installed themes.

Themes may include:

PHP
CSS
JavaScript
Images
Fonts
Templates

51. Uploads

wp-content/uploads/

commonly contains uploaded media.

For example:

uploads/
├── 2026/
│   ├── 01/
│   ├── 02/
│   └── 08/

WordPress organizes media using dates by default, depending on settings.

52. Nginx root

Suppose your Nginx configuration contains:

root /storage/websites/templates.cresignsys.com/public;

Then Nginx maps URL paths to filesystem paths.

For example:

URL:
/logo.png

can map conceptually to:

/storage/websites/templates.cresignsys.com/public/logo.png

53. URL-to-File Mapping

This is fundamental.

URL
 ↓
Nginx
 ↓
root
 ↓
filesystem path

For example:

https://templates.cresignsys.com/css/style.css

could map to:

/storage/websites/templates.cresignsys.com/public/css/style.css

if the file exists and the configuration permits it.

54. But WordPress URLs Are Different

Consider:

https://templates.cresignsys.com/about/

There may not be a physical:

/about/

directory.

Instead:

/about/
 ↓
Nginx routing
 ↓
index.php
 ↓
WordPress

This is why try_files is important.

55. Filesystem vs URL

Don’t confuse:

URL path

with:

filesystem path

Example:

URL:
/about/

Filesystem:
/storage/websites/templates.cresignsys.com/public/

WordPress decides what /about/ means.

56. index.php

A typical WordPress installation has:

index.php

at the site root.

Nginx may use it as the fallback application entry point.

Conceptually:

Unknown URL
    ↓
index.php
    ↓
WordPress

57. Filesystem Permissions

Now combine the filesystem with our previous lesson.

Suppose:

Nginx/PHP-FPM
        ↓
/storage/websites/...

Linux checks:

Who is requesting?
        ↓
Which file?
        ↓
Owner/group/permissions
        ↓
Allowed?

58. Directory Traversal

Suppose the path is:

/storage/websites/site/public/index.php

The process needs appropriate permission to traverse the directories:

/storage
/storage/websites
/storage/websites/site
/storage/websites/site/public

before it can access the file.

This is why permissions on parent directories matter.

59. Ownership Chain

A request might involve:

Nginx
 ↓
PHP-FPM
 ↓
www-data
 ↓
filesystem

If www-data cannot access a required file:

Permission denied

can occur.

60. stat

A useful command for examining a file:

stat /storage/websites/templates.cresignsys.com/public/index.php

It shows metadata such as:

File
Size
Blocks
Permissions
UID
GID
Access time
Modify time
Change time

61. namei

A very useful command for debugging path permissions:

namei -l /storage/websites/templates.cresignsys.com/public/index.php

It can show each component of the path and its permissions.

This is extremely useful when diagnosing:

Permission denied

62. Symbolic Links

Linux supports:

Symbolic links

Example:

current
  ↓
/storage/websites/site/releases/2026-08-13

A symlink points to another path.

Check with:

ls -l

You may see:

current -> releases/2026-08-13

63. Why Symlinks Matter in Hosting

Symlinks can be used for:

Deployments
Shared assets
Version switching
Configuration
Certificates

They are common in sophisticated deployment systems.

64. Hard Links

Linux filesystems can also have:

Hard links

A hard link is another directory entry referring to the same underlying filesystem object/inode.

Conceptually:

name A ──┐
         ├── inode ── data
name B ──┘

This is different from a symbolic link.

65. File Deletion

A deeper filesystem concept:

Deleting a filename doesn’t necessarily immediately destroy the underlying data if another hard link still references the inode, or if an open process still holds the file open.

This leads to an important Linux troubleshooting concept.

66. Deleted but Still Open

Suppose:

application
 ↓
opens large.log
 ↓
file deleted

The directory entry may disappear, but the process can still have the file open.

Disk space can remain occupied until the file descriptor is closed.

Tools such as:

lsof

can help investigate this.

67. lsof

lsof means:

List Open Files

Linux treats many resources as file descriptors, so lsof can show:

Files
Sockets
Deleted-but-open files

For example:

sudo lsof | head

68. Why This Matters for Logs

Suppose an application writes to:

/var/log/application.log

and the file is deleted while the process still has it open.

You might see:

df -h

showing unexpectedly high disk usage even though:

du

doesn’t seem to account for it.

Deleted-but-open files can be one explanation.

69. du

Use:

du -sh /storage/websites/*

to estimate directory usage.

For a specific site:

du -sh /storage/websites/templates.cresignsys.com

This is useful for hosting capacity monitoring.

70. df vs du

This distinction is very important.

df

Reports filesystem-level space usage.

df -h

du

Estimates space consumed by files/directories.

du -sh directory

They can sometimes disagree for legitimate reasons.

71. Filesystem Mount Boundary

Suppose:

/storage

is a separate filesystem.

Then:

du -sh /

may not represent total storage usage across all mounted filesystems in the way you expect.

Always understand your mount structure.

72. Mount Hierarchy

Imagine:

/
├── etc
├── var
└── storage
      ↓
    separate filesystem

The directory:

/storage

is a mount point.

The contents of the mounted filesystem appear there.

73. Mounting Hides Underlying Directory Contents

This is a subtle but important concept.

If /storage had files before another filesystem was mounted there:

Before:
 /storage
 ├── old-file
 └── old-folder

After mounting another filesystem:

/storage
 ↓
mounted filesystem

the old underlying contents are hidden while the mount is active.

They aren’t necessarily deleted.

74. /etc/fstab

Persistent mounts are often configured through:

/etc/fstab

This tells Linux how certain filesystems should be mounted.

You can inspect it with:

cat /etc/fstab

Don’t modify it blindly.

A bad entry can interfere with booting.

75. Mount at Boot

Conceptually:

Server boots
 ↓
systemd
 ↓
mount filesystems
 ↓
/storage available
 ↓
hosting services start

This matters if your websites depend on a separate storage volume.

76. If /storage Disappears

Imagine Nginx expects:

/storage/websites/site/public

but the storage filesystem isn’t mounted.

Then the expected files may not be available.

Possible result:

Nginx
 ↓
wrong/empty filesystem path
 ↓
website failure

The exact behavior depends on what exists underneath the mount point and the configuration.

77. This Is Why Mounts Matter to Hosting

Your hosting architecture may therefore be:

Cloud Storage
      ↓
Filesystem
      ↓
/storage
      ↓
/storage/websites
      ↓
domain
      ↓
public
      ↓
WordPress

This is a complete storage chain.

78. Website Storage Architecture

A clean conceptual model is:

/storage
   │
   └── websites
         │
         ├── site1.com
         │     └── public
         │
         ├── site2.com
         │     └── public
         │
         └── site3.com
               └── public

This makes automated hosting easier.

79. Why public/?

The name:

public

is a convention meaning:

Files intended to be exposed through the web server.

It is not a special Linux directory.

You could technically call it:

web
html
htdocs
public_html
site

depending on your design.

80. Public vs Private Files

A good web application separates:

Public

from:

Private

Conceptually:

website
├── public
│   ├── index.php
│   ├── wp-content
│   └── assets
│
└── private
    ├── backups
    ├── secrets
    └── deployment files

Only the intended public directory should normally be exposed as the web root.

81. Why This Is a Security Principle

Suppose your website root accidentally exposes:

database-backup.sql
.env
private-key
backup.zip

An attacker might download sensitive information if the web server serves those files.

Therefore:

Web root should contain only what needs to be web-accessible.

82. Your SSL Files Are Outside the Website

Notice your Let’s Encrypt certificate is stored under:

/etc/letsencrypt/

not:

/storage/websites/templates.cresignsys.com/public/

This is intentional.

Private TLS keys should not be publicly downloadable website files.

83. Nginx Configuration Is Also Outside the Website

Your Nginx site configuration is under something like:

/etc/nginx/sites-enabled/

rather than inside:

public/

This separates:

Application files

from:

Web-server configuration

84. WordPress Configuration

WordPress has:

wp-config.php

which contains sensitive database configuration.

It must be protected from direct download.

A properly configured PHP/Nginx environment treats .php as executable PHP rather than serving its source code as plain text.

85. Complete Storage-to-Web Chain

Now connect everything:

Cloud storage
      ↓
Block device
      ↓
Filesystem
      ↓
Mount
      ↓
/storage
      ↓
/storage/websites
      ↓
/storage/websites/templates.cresignsys.com
      ↓
public
      ↓
WordPress files
      ↓
Nginx root
      ↓
HTTP URL

86. URL-to-Storage Example

Browser:

https://templates.cresignsys.com/logo.png

Nginx:

server_name
 ↓
root

Filesystem:

/storage/websites/templates.cresignsys.com/public/logo.png

Then:

Storage
 ↓
Linux filesystem
 ↓
Nginx
 ↓
HTTP response
 ↓
TLS
 ↓
Browser

87. Dynamic URL Example

Browser:

https://templates.cresignsys.com/about/

Filesystem may not contain:

public/about/index.html

Instead:

/about/
 ↓
Nginx
 ↓
try_files
 ↓
index.php
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
HTML

So the URL isn’t necessarily a physical file.

88. Static and Dynamic Architecture

You can now see the difference clearly.

Static

URL
 ↓
Nginx
 ↓
Filesystem
 ↓
File
 ↓
Response

Dynamic

URL
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL
 ↓
HTML
 ↓
Response

89. Practical Commands

Run these on your VPS:

Understand /storage

findmnt /storage

See devices

lsblk

See filesystem types

df -T

See disk usage

df -h

See inode usage

df -i

See website directory size

du -sh /storage/websites/templates.cresignsys.com

Inspect website files

ls -lah /storage/websites/templates.cresignsys.com/public

Inspect file metadata

stat /storage/websites/templates.cresignsys.com/public/index.php

Inspect every path component

namei -l /storage/websites/templates.cresignsys.com/public/index.php

90. Do Not Change Anything Yet

For this lesson, use these commands primarily for observation.

Especially avoid experimenting with:

mount
umount
chmod -R
chown -R
/etc/fstab

until the filesystem and permission model is fully understood.

These can affect your live websites.

91. Deep Mental Model

Your server storage is now:

                 CLOUD STORAGE
                       │
                       ▼
                  BLOCK DEVICE
                       │
                       ▼
                   FILESYSTEM
                       │
                       ▼
                    MOUNT
                       │
                       ▼
                   /storage
                       │
                       ▼
                   /websites
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
        Site A       Site B       Site C
          │            │            │
        public       public       public
          │
          ▼
      WordPress

And Nginx sits above this:

Browser
   ↓
HTTP
   ↓
Nginx
   ↓
root
   ↓
/storage/websites/.../public

92. The Most Important Concepts

Memorize:

/
= filesystem root

/root
= root user's home

/etc
= configuration

/var
= changing system/application data

/var/log
= logs

/run
= runtime state

/proc
= kernel/process information

/sys
= device/kernel subsystem information

/home
= user home directories

/usr
= system programs/libraries/data

/storage
= your chosen hosting storage location

And:

Storage
 ↓
Filesystem
 ↓
Mount
 ↓
Directory
 ↓
File

93. The Bigger Picture

We have now covered:

Hardware
 ↓
Linux Kernel
 ↓
Virtual Memory
 ↓
Processes
 ↓
Filesystem
 ↓
Network
 ↓
Services
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

We are approaching the point where we can understand the VPS as an integrated system rather than isolated technologies.

Lesson 034 Summary

The key idea is:

A path such as /storage/websites/templates.cresignsys.com/public/ is a location in Linux’s unified filesystem namespace. It may ultimately map through a mounted filesystem to cloud storage. Nginx uses that filesystem location as part of serving your website.

The complete relationship:

URL
 ↓
Nginx
 ↓
Filesystem path
 ↓
Mount
 ↓
Filesystem
 ↓
Block storage

or, for WordPress:

URL
 ↓
Nginx
 ↓
index.php
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Filesystem + MySQL

Next Lesson — 035

Linux Networking Inside Your VPS

We will go deeper into:

Network Interface
 ↓
MAC address
 ↓
IP address
 ↓
Subnet
 ↓
Gateway
 ↓
Routing table
 ↓
ARP / Neighbor Discovery
 ↓
TCP/UDP
 ↓
Port
 ↓
Socket
 ↓
Nginx

Then we will connect this directly to your Oracle Cloud VPS:

Internet
 ↓
Public IP
 ↓
VNIC
 ↓
Subnet
 ↓
Security List / NSG
 ↓
Ubuntu
 ↓
Nginx :443

That will explain exactly how an HTTPS packet from a user’s browser reaches your templates.cresignsys.com Nginx process inside the VPS.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts