The last blog introduced my usage of fnNAS; this blog briefly shares my research into the system itself.
The last blog introduced my usage of fnNAS; this blog briefly shares my research into the system itself.
This article assumes readers have some Linux and NAS-tinkering background; if not, don’t force yourself to read and understand it…
Command-Line Login
SSH Service
Make sure the system’s SSH service is on:
1 2 3 4 5
➜ ~ ssh [email protected] [email protected]'s password: Linux HomeFN 6.12.18-trim #5 SMP PREEMPT_DYNAMIC Thu Mar 27 10:30:00 CST 2025 x86_64 Last login: Sun May 18 11:06:10 2025 from 192.168.101.221 corvo@HomeFN:~$
After the first login, I found typing the password every time annoying, so I added a public key to the machine — you can add this directory and file yourself:
1 2
corvo@HomeFN:~$ ls ~/.ssh/authorized_keys /home/corvo/.ssh/authorized_keys
Switching to the root User
You can also switch to the root user; just enter the password normally:
1 2 3
corvo@HomeFN:~$ sudo su - root [sudo] password for corvo: root@HomeFN:~# # already switched to the root user
System Components
Operating System
This is a Debian 12 system. I personally love this choice — it stays consistent with my other NAS systems.
Among these, the two fuse.rclone disks are Baidu Cloud and Aliyun Drive; the cifs-mounted directory is my own smb server,
and the other two btrfs systems are virtual hard drives I mounted myself.
# and the rclone configuration inside root@HomeFN:/usr/trim/nginx# cat /etc/mountmgr/rclone/1000.conf [1000-1-c86c2633] type = webdav user = 1000_qxSsjpVcKsVORqoA pass = xxxxxxxxxxx url = http://127.0.0.1:15244
[1000-1-4a74aa03] type = webdav url = http://127.0.0.1:15244 user = 1000_0XKC8OEuwEaVrUvn pass = xxxxxxxxxxx
# The 15244 here is listened on by `cloud_storage_dav`; after providing the webdav interface, rclone mounts it as a local directory — # very much in line with Linux usage logic.
User Groups
Each application has its own user; there appears to be permission control too:
fnNAS uses PostgreSQL as its database. The interested can research its databases and tables — it looks like fnNAS takes AI-related content quite seriously, with a separate AI-related database.
This part was my original motivation for writing this article, because I started this system with Proxmox, and later it’s possible to increase disk size using PVE’s built-in features.
So I researched the fnNAS system and its disk management, hoping to help users who also use PVE.
Data is priceless — please back up before operating!!!
Data is priceless — please back up before operating!!!
Data is priceless — please back up before operating!!!
Some content references: On fnNAS storage disk expansion under virtualization; another part I learned from ChatGPT.
Please note: this procedure only suits single-disk users. I myself only understand RAID’s functionality but have no actual RAID operation experience.
This part isn’t for beginners — it’s my record of my own operation scheme, for convenient disk management later.
root@HomeFN:/usr/trim/etc# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdb 8:16 0 52G 0 disk └─sdb1 8:17 0 52G 0 part └─md0 9:0 0 52G 0 raid1 └─trim_5ab5694e_275a_417b_8f53_88510b630e5f-0 253:0 0 52G 0 lvm /vol1 sdc 8:32 0 6G 0 disk └─sdc1 8:33 0 6G 0 part └─md1 9:1 0 6G 0 raid1 └─trim_fc35013f_f739_4592_942f_d054200d2a3a-0 253:1 0 6G 0 lvm /vol2
Determine the disk you want to expand; here I’ll demonstrate with the /vol2 disk, expanding from 6G to 8G.
Adjusting the Disk in PVE
Select the disk to expand:
Add 2G of disk:
Confirm the disk has been added
1 2 3 4 5 6
root@HomeFN:/usr/trim/etc# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdc 8:32 0 8G 0 disk # already 8G here └─sdc1 8:33 0 6G 0 part └─md1 9:1 0 6G 0 raid1 └─trim_fc35013f_f739_4592_942f_d054200d2a3a-0 253:1 0 6G 0 lvm /vol2
Our goal is actually to expand the final lvm partition to 8G as well, and it’s done.
Unmounting the Disk
First unmount the disk in system settings. I didn’t use the command line because fnNAS processes would occupy it — unmounting from the web side is safer.
Welcome to fdisk (util-linux 2.38.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command.
GPT PMBR size mismatch (12582911 != 16777215) will be corrected by write. The backup GPT table is not on the end of the device. This problem will be corrected by write. This disk is currently in use - repartitioning is probably a bad idea. It's recommended to umount all file systems, and swapoff all swap partitions on this disk. Command (m for help): p Disk /dev/sdc: 8 GiB, 8589934592 bytes, 16777216 sectors Disk model: QEMU HARDDISK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: FA6EEB5E-CA1C-4B0D-A7B3-F5CE97C59BC7 Device Start End Sectors Size Type /dev/sdc1 2048 12580863 12578816 6G Linux RAID Command (m for help): d Selected partition 1 Partition 1 has been deleted. Command (m for help): n Partition number (1-128, default 1): First sector (34-16777182, default 2048): Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-16777182, default 16775167): Created a new partition 1 of type 'Linux filesystem' and of size 8 GiB. Partition #1 contains a linux_raid_member signature. Do you want to remove the signature? [Y]es/[N]o: N # the current signature MUST be kept Command (m for help): t Selected partition 1 Partition type or alias (type L to list all): 42 Changed type of partition 'Linux filesystem' to 'Linux RAID'. Command (m for help): w The partition table has been altered. Syncing disks.
View the adjustment result:
1 2 3 4 5 6
root@HomeFN:/usr/trim/etc# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdc 8:32 0 8G 0 disk └─sdc1 8:33 0 8G 0 part # partition became 8G └─md1 9:1 0 6G 0 raid1 └─trim_fc35013f_f739_4592_942f_d054200d2a3a-0 253:1 0 6G 0 lvm /vol2
Adjusting the raid
1 2 3 4 5 6 7 8
root@HomeFN:/usr/trim/etc# mdadm --grow /dev/md1 --size=max mdadm: component size of /dev/md1 has been set to 8381440K root@HomeFN:/usr/trim/etc# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdc 8:32 0 8G 0 disk └─sdc1 8:33 0 8G 0 part └─md1 9:1 0 8G 0 raid1 # raid became 8G └─trim_fc35013f_f739_4592_942f_d054200d2a3a-0 253:1 0 6G 0 lvm /vol2
Adjusting the lvm Volume
1 2 3 4 5 6 7 8 9 10 11
root@HomeFN:/usr/trim/etc# pvresize /dev/md1 root@HomeFN:/usr/trim/etc# lvresize /dev/trim_fc35013f_f739_4592_942f_d054200d2a3a/0 -l +100%FREE Size of logical volume trim_fc35013f_f739_4592_942f_d054200d2a3a/0 changed from 5.99 GiB (1534 extents) to 7.99 GiB (2046 extents). Logical volume trim_fc35013f_f739_4592_942f_d054200d2a3a/0 successfully resized.
root@HomeFN:/usr/trim/etc# btrfs filesystem resize max /vol2/ Resize device id 1 (/dev/mapper/trim_fc35013f_f739_4592_942f_d054200d2a3a-0) from 5.99GiB to max
root@HomeFN:/usr/trim/etc# df -Th /dev/mapper/trim_fc35013f_f739_4592_942f_d054200d2a3a-0 btrfs 8.0G 5.9M 7.5G 1% /vol2 # the filesystem also became 8G
I only did this operation on a single disk; I’ve never operated other RAID forms — I suggest caution.
System Updates
So far I’ve only installed one version. This system’s later updates are also a question — including the system itself and internal components. I hope the development team already has a complete plan.
Summary
I think fnNAS’s underlying system and technology choices are already very good: Debian 12, PostgreSQL, Docker, Rclone, with most components written in Golang —
maximum freedom, and convenient integration with my previous NAS systems; clients support many platforms too. I don’t think there’s any chance I’d refuse to keep using this NAS platform.
Another point: I worry about their target users. If the target users are NAS enthusiasts like me, this project is afraid it will lose money to the bottom — I neither want to spend more nor need technical support…
I’m quite curious what direction their value-added services will develop. If some component charges fees, how can one component’s revenue bear all components’ development — will there be imbalance between teams?
In my view this service must go the enterprise direction: consulting like CentOS, licensing like PVE, or acquisition by a manufacturer like Xiaomi as an integrated system.
At the current stage, I’ll try using some features, but won’t migrate all services over — unless the project team obtains a more stable revenue stream before the money burns out.
Making users believe the profit model is sustainable is far harder than letting users experience it once. I hope you succeed.
