Sharing ZFS dataset via SMB on Proxmox using CT turnkey fileserver

[K0rben]

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:

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

 

[UdoB]

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.

 

[Randell]

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.

 

[K0rben]

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:

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:

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):

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:

zfs list

1.2. Create the dataset if needed:

zfs create tank/backups

1.3. Ensure the dataset is mounted:

ls /tank/backups

1.4. (Optional) Set write permissions:

chmod 777 /tank/backups

---

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

2.1. Edit the container config:

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

2.2. Add a bind mount:

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

2.3. Restart the container:

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

2.4. Check the mount in the container:

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

---

3. Install and configure Samba in the LXC container​

3.1. Install Samba:

apt update && apt install samba -y

3.2. Configure Samba:

nano /etc/samba/smb.conf

Add the following section:

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

3.3. Set directory permissions:

chmod 777 /mnt/backups

3.4. Restart Samba:

systemctl restart smbd

---

4. Access the Samba share from Windows​

4.1. Access the share:

• From Windows, open File Explorer and use:
  
  

  \\<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:

ls /mnt/backups

5.2. Check on the Proxmox host:

ls /tank/backups

 

[billy999]

Thank you for the guide, but Im interested if POSIX ACL and samba DOS attributes (via xattr) are working this way as well

 

[UdoB]

./install.sh: line 114: pveam: command not found

That is strange as that binary comes from a core package:

~# 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!

 

[K0rben]

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:
   
   

   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
   
   

   apt update
   apt install acl attr

   
   
   
3. Check the file’s permissions:
   
   

   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):
   
   

   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:
   
   

   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