But in Nethserver 8, how can i define the default locations/disks for samba shares, this was an option in version 7 but for the life of me i can’t find it in version 8.
We don’t have a preferred method yet. Some approaches were discussed in this thread:
As an alternative, the disk could be mounted under a volume _data/ path, but I prefer the previous approach because it preserves[1] disk data if the module is removed and doesn’t rely on Podman’s default volume path.
Adding --one-file-system argument to rm -rf of remove-module action could be a future improvement. ↩︎
Seems a bit of an oversight for this not to have been included in the setup for Samba shares though.
E.G you create a hardware server with a small NVME for the OS and large redundant Drives for data, but shares will only be created on the original installation target drive.
Hi,
I fully support the suggestion of @uncle_numpty , so we can put the small actually needed data shares on fast OS-disk or separate SSD, and the very large archieved data-stores on slower but much bigger spinners, instead of using separate NAS.
By the way (haven’t took a deeper look until now), how to put the maildir on a separate larger disk ?
Greetings, Mario
@davidep
First of all, thanks for all the work done on Nethserver 8.
I did a test and saw that Samba stores the shared folder in /home and it is considered good practice to point the home folder to a dedicated partition. Is there any advice on pointing the home folder to a disk dedicated to Samba? That would solve my problem.
We are still working on improving support for different storage
configurations tailored to specific tasks. Here’s what we currently have:
A single small, fast disk for everything, which works well for test and
small installations.
A small, fast root disk with /home mounted on a separate small and
fast disk. Rootless modules still require a fast disk to read container
images, especially during service startups. You can find a script in the
manual to help move /home to a new disk here.
In the coming weeks, we plan to add support for a third scenario: allowing each volume of every module instance to be mounted to a custom location. This would accommodate large, slower disks or even remote filesystems.