I have a usecase that involves a lot of calculations that are causing excessive TBW on my drives. I want to provide a network ramdisk to share via smb for my other servers to read and write to.

Would it work to add these lines to smb-extra.conf?

[ramdisk]

path=/dev/shm

browseable = yes

public = yes

writeable = yes

Should yes if /dev/shm is the ram disk.

Settings > SMB > smb extra:

Here is How I would go about it though...

User script plugin at first array start.

Create a dedicated RAM disk (tmpfs)

User scirp plugin for reboots

# create a mount point
mkdir -p /mnt/ramdisk

# mount a tmpfs of the size you want (example: 32G). 
# mode=1777 = world-writable like /tmp, with the sticky bit.
mount -t tmpfs -o size=32G,mode=1777,nosuid,nodev tmpfs /mnt/ramdisk

# verify
df -h /mnt/ramdisk

*this way /mnt/ramdisk is my share path and its a 32 GB Ram allocation...

Better to edit eh web UI...
Add this block to Settings → SMB → SMB Extras (or edit /boot/config/smb-extra.conf

Samba options:

[ramdisk]
   path = /mnt/ramdisk
   browseable = yes
   public = yes
   guest ok = yes
   read only = no
   writeable = yes
   force user = nobody
   force group = users
   create mask = 0666
   directory mask = 0777
   oplocks = no

I would avoid trying to use /dev/shm directly...

If you really want to share /dev/shm

It does work, but be aware it’s shared OS/containers space and defaults to ~½ of RAM. If you still want to, use:*(That’s essentially what you proposed; I just added a little safety/compatibility lines.) Reference thread where this idea came up is here...

[ramdisk]
path = /dev/shm
browseable = yes
public = yes
guest ok = yes
read only = no
writeable = yes
force user = nobody
force group = users
oplocks = no

Quick tests

• Local write test:

  dd if=/dev/zero of=/mnt/ramdisk/test.bin bs=1M count=1024 status=progress
  

• From a client, copy in/out and confirm speed and that files vanish on server reboot (expected—RAM only).

Notes

• Volatility: This is RAM—data disappears on reboot/array stop. Use it for scratch only.

• Sizing: Adjust size= to whatever you need; consider separate RAM disks per workload if you want isolation.

• Performance knobs: Usually leave Samba defaults; oplocks = no reduces corruption risk for DB-like workloads hitting a network share. If you need strict durability semantics, you can add strict sync = yes (but that will slow it down).

Edited October 14, 2025Oct 14 by bmartino1
scirpt fixes and updates