Sharing ZFS dataset via SMB on Proxmox using CT turnkey fileserver

K

K0rben

New Member
Oct 17, 2024
3
5
3
Hello,

I'm reaching out because I want to set up a simple configuration: sharing my ZFS dataset via SMB so I can access it from my Windows PC. However, I don’t want to install SMB directly on my Proxmox server (PVE).

Here’s my current configuration on Proxmox:

Code: 
root@pve:~# zfs list

tank            7.95G  3.59T   660M  /tank

tank/backups     128K  3.59T   128K  /tank/backups

tank/isos        128K  3.59T   128K  /tank/isos

tank/vm-drives  7.29G  3.59T  7.29G  /tank/vm-drives


root@pve:~# zpool list

NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT

tank  5.58T  11.9G  5.57T        -         -     0%     0%  1.00x    ONLINE  -

The pool is configured in raidz1.

My goal is to share this ZFS pool via SMB, but I don’t want to install SMB directly on my Proxmox node. That’s why I opted to use a CT turnkey fileserver to manage the SMB share.

However, when I tried this approach, I noticed that the files were being stored on the CT itself, rather than on my ZFS "tank" pool, which is not what I want. My idea is for the CT turnkey fileserver to act as a bridge to access the data stored on my ZFS dataset, without using the CT as a separate storage space.

I’m wondering how to configure this setup so that files are directly stored on the ZFS dataset while using the CT turnkey fileserver to handle the SMB share. I’ve also seen that some people use OpenMediaVault or Nextcloud, but this seems overkill for my needs.

Do you have any recommendations on how I can achieve this SMB share setup without installing SMB directly on the Proxmox server?

If anyone has feedback on this architecture, or thinks it’s a bad approach, I’m open to suggestions and advice.

Thank you in advance for your help
 
Take a look at https://github.com/bashclub/zamba-lxc-toolbox

They do Samba with ZFS-snapshots which are visible in the Windows File Explorer. It is a Container, so no VM overhead with passthrough-problems required and all data is easily accessible on the host without any tricks.
 
  • Like
Reactions: Kingneutron
Bind mount from the host to the LXC, then share from there. You'd have a line in your conf something like:

mp0: /tank/backups,mp=/mnt/backups,replicate=0

Then inside the LXC, you share /mnt/backups

If I remember correctly, bind mounts are not recursive, so you can't just bind mount /tank, you need to bind mount each dataset you want to expose to the LXC and thus share.
 
Last edited:
  • Like
Reactions: agarg and Kingneutron
I successfully configured Samba via a Turnkey Fileserver container after encountering issues with Zamba.

When I tried to install zmb-standalone, I got the following error message:

Code: 
Loading config file '/root/zamba-lxc-toolbox/conf/zamba.conf'...
./install.sh: line 114: pveam: command not found

After some research, I decided to stop using Zamba and instead installed Samba directly using the following command in the container:

Code: 
apt install samba -y

To mount my ZFS dataset in the container, I followed Randell's recommendation and added the following bind mount to my container configuration (ID 400):

Code: 
mp0: /tank/backups,mp=/mnt/backups,replicate=0

It works perfectly

I’ll write up the complete procedure for anyone who needs to do the same.

Thanks a lot for your help!

------------------------------------------

1. Create or verify the ZFS dataset on the Proxmox host​

1.1. Check existing datasets:

Code: 
zfs list

1.2. Create the dataset if needed:

Code: 
zfs create tank/backups

1.3. Ensure the dataset is mounted:

Code: 
ls /tank/backups

1.4. (Optional) Set write permissions:

Code: 
chmod 777 /tank/backups

2. Configure the LXC container to mount the ZFS dataset​

2.1. Edit the container config:

Code: 
nano /etc/pve/lxc/<CT-ID>.conf

2.2. Add a bind mount:

Code: 
mp0: /tank/backups,mp=/mnt/backups,acl=1,replicate=0

2.3. Restart the container:

Code: 
pct stop <CT-ID> && pct start <CT-ID>

2.4. Check the mount in the container:

Code: 
pct enter <CT-ID>
ls /mnt/backups

3. Install and configure Samba in the LXC container​

3.1. Install Samba:

Code: 
apt update && apt install samba -y

3.2. Configure Samba:

Code: 
nano /etc/samba/smb.conf

Add the following section:

Code: 
[backups]
path = /mnt/backups
browseable = yes
read only = no
guest ok = yes
create mask = 0755
force user = root

3.3. Set directory permissions:

Code: 
chmod 777 /mnt/backups

3.4. Restart Samba:

Code: 
systemctl restart smbd

4. Access the Samba share from Windows​

4.1. Access the share:

  • From Windows, open File Explorer and use:

    Code: 
    \\<LXC-Container-IP>\backups
4.2. Create a test file:

  • Create a file like testfile.txt to verify the share.

5. Verify that files created via Samba appear in the ZFS dataset​

5.1. Check in the container:

Code: 
ls /mnt/backups

5.2. Check on the Proxmox host:

Code: 
ls /tank/backups
 
  • Like
Reactions: waltar, agarg and UdoB
Thank you for the guide, but Im interested if POSIX ACL and samba DOS attributes (via xattr) are working this way as well
 
K0rben said:
./install.sh: line 114: pveam: command not found
Click to expand...
That is strange as that binary comes from a core package:
Code: 
~# dpkg -S $(which pveam )
pve-manager: /usr/bin/pveam

But hey, as long as you are fine with your solution it is great! :)

PS: you may take a look into their template of the "smb.conf" (hidden in an install script) to get "Shadow copies" and some other good stuff.

Have fun!
 
Hi,

Yes and no.
Samba DOS attributes (via xattr) and POSIX ACLs work. Here's the procedure I followed to manage the "read-only" status on a shared file between a Linux container (CT) and Windows:

Steps:​

  1. Create a test file:

    Code: 
    touch /mnt/backups/testfile

  2. Install necessary packages for managing ACLs and extended attributes:
    - Using chmod on the file will not affect its "read-only" status in Windows. You need to use getfattr and setfattr to manage the DOS attributes
    - I encountered some mandb permission-related errors, but these were related to managing manual pages and did not affect the functioning of Samba or the package installation

    Code: 
    apt update
apt install acl attr


  3. Check the file’s permissions:

    Code: 
    ls -l /mnt/backups/testfile

    This shows standard POSIX permissions, where rwx indicates read, write, and execute permissions for owner, group, and others. However, these permissions do not affectthe "read-only" status in Windows via Samba.

  4. Check the file’s extended attributes (xattr):

    Code: 
    getfattr -d /mnt/backups/testfile

    If you see the user.DOSATTRIB attribute, it contains information about the file's DOS attributes (such as "read-only") for Windows. The presence of this attribute likely indicates that the file is marked "read-only" on Windows, even though POSIX permissions may allow write access.

  5. Test the "read-only" attribute from Windows: I went to the file properties in Windows, manually checked the "read-only" box, and observed that the user.DOSATTRIB attribute was updated accordingly.

  6. Disable the "read-only" attribute by removing the user.DOSATTRIB extended attribute:

    Code: 
    setfattr -x user.DOSATTRIB /mnt/backups/testfile

  7. Verify in Windows: After removing the attribute, I returned to Windows, and the "read-only" box was no longer checked, confirming the change.

Nb:​

From the Linux CT, you cannot directly see the "read-only" status as interpreted by Windows. You need to check the user.DOSATTRIB attribute or verify the status directly from Windows to confirm.


Thanks for your help
 
  • Like
Reactions: waltar and agarg
K0rben said:
Hi,

Yes and no.
Samba DOS attributes (via xattr) and POSIX ACLs work. Here's the procedure I followed to manage the "read-only" status on a shared file between a Linux container (CT) and Windows:

Steps:​

  1. Create a test file:

    Code: 
    touch /mnt/backups/testfile

  2. Install necessary packages for managing ACLs and extended attributes:
    - Using chmod on the file will not affect its "read-only" status in Windows. You need to use getfattr and setfattr to manage the DOS attributes
    - I encountered some mandb permission-related errors, but these were related to managing manual pages and did not affect the functioning of Samba or the package installation

    Code: 
    apt update
apt install acl attr


  3. Check the file’s permissions:

    Code: 
    ls -l /mnt/backups/testfile

    This shows standard POSIX permissions, where rwx indicates read, write, and execute permissions for owner, group, and others. However, these permissions do not affectthe "read-only" status in Windows via Samba.

  4. Check the file’s extended attributes (xattr):

    Code: 
    getfattr -d /mnt/backups/testfile

    If you see the user.DOSATTRIB attribute, it contains information about the file's DOS attributes (such as "read-only") for Windows. The presence of this attribute likely indicates that the file is marked "read-only" on Windows, even though POSIX permissions may allow write access.

  5. Test the "read-only" attribute from Windows: I went to the file properties in Windows, manually checked the "read-only" box, and observed that the user.DOSATTRIB attribute was updated accordingly.

  6. Disable the "read-only" attribute by removing the user.DOSATTRIB extended attribute:

    Code: 
    setfattr -x user.DOSATTRIB /mnt/backups/testfile

  7. Verify in Windows: After removing the attribute, I returned to Windows, and the "read-only" box was no longer checked, confirming the change.

Nb:​

From the Linux CT, you cannot directly see the "read-only" status as interpreted by Windows. You need to check the user.DOSATTRIB attribute or verify the status directly from Windows to confirm.


Thanks for your help
Click to expand...
Superbly done. Very useful for NooB like me. I will try this out. I have a debian box with zfs listed already. I forgot the commands I had used but they were simple:
Code: 
root@micro:/mnt/datastore/micro-12tb# zfs list
NAME                   USED  AVAIL     REFER  MOUNTPOINT
micro-12tb            8.86T  1.91T     1.82T  /mnt/datastore/micro-12tb
root@micro:/mnt/datastore/micro-12tb#
 
Randell said:
Bind mount from the host to the LXC, then share from there. You'd have a line in your conf something like:

mp0: /tank/backups,mp=/mnt/backups,replicate=0

Then inside the LXC, you share /mnt/backups

If I remember correctly, bind mounts are not recursive, so you can't just bind mount /tank, you need to bind mount each dataset you want to expose to the LXC and thus share.
Click to expand...
I can install Proxmox on a 128GB SSD for this purpose and then zpool import a raidz1 dataset.

From there, I can install a lxc container like @K0rben and then use your suggested bind settings to access the dataset from this new container.

Can I install another container say for Wordpress and then bind the same dataset again into the second container? The files will be uncommon.

Pls advise.
 
waltar said:
Yes, for sure.
Click to expand...
I just tested and it worked like a charm. Amazing to pass a humongous file system into a container!

I gave it a cursory look to turnkey file server and to me it looks nearly identical to doing a basic Debian install and then install webmin. The webmin pulls the samba modules by itself as needed. It gave me a 12321 port to use instead of 10000.

Anything I missed?
 
Last edited:
agarg said:
I just tested and it worked like a charm. Amazing to pass a humongous file system into a container!

I gave it a cursory look to turnkey file server and to me it looks nearly identical to doing a basic Debian install and then install webmin. The webmin pulls the samba modules by itself as needed. It gave me a 12321 port to use instead of 10000.

Anything I missed?
Click to expand...
Doesn't look like it.

I used Debian, then cockpit with the 45drives cockpit-file-sharing plugin
 
  • Like
Reactions: agarg
Randell said:
I used Debian, then cockpit with the 45drives cockpit-file-sharing plugin
Click to expand...
So you sent zfs mount point to LXC mount in a debian container and on the container your cockpit+45drive worked fine? And then like:
Code: 
https://mydebian_lxc.lan:9090/
 
agarg said:
So you sent zfs mount point to LXC mount in a debian container and on the container your cockpit+45drive worked fine? And then like:
Code: 
https://mydebian_lxc.lan:9090/
Click to expand...
Yup. I then share those mounts out with smb and NFS.

But anything inside the container to serve the mount, like a turnkey or the like would probably be fine. I just liked the look of the cockpit+45drive plugin, lol.

Then again, I only have about 6 users and I don't do anything fancy with smb or NFS.
 
  • Like
Reactions: agarg
Randell said:
Yup. I then share those mounts out with smb and NFS.

But anything inside the container to serve the mount, like a turnkey or the like would probably be fine. I just liked the look of the cockpit+45drive plugin, lol.

Then again, I only have about 6 users and I don't do anything fancy with smb or NFS.
Click to expand...
I beat you on that - I have one potential users (besides myself, my wife.)!!

I have a very old HP Proliant Microserver box with unused hdd. Something to play with. I agree that cockpit has a more elegant looking interface. Webmin (including my memory from 10 years ago) is functional, powerful and effective but not an eye candy.
 
Last edited:
You must log in or register to reply here.
Top Bottom