Access Denied creating CIFS share between Proxmox and TrueNAS Scale

[sgt_jamez]

TrueNAS Scale v21.06-BETA (joined to an AD domain)
Proxmox v7.0-10

I'm running into a problem trying to create a CIFS share between Proxmox and a dataset on TrueNAS Scale.
Using the Proxmox GUI, I enter a name for the share, the TrueNAS IP, and the share credentials.
There's a dropdown that will allow you to choose the share once the creds are authenticated. When I do this, I get a
get an access denied error message. My reading on the web indicates this is a permissions issue on the TrueNAS side for the
share.

I tried using the TrueNAS root credentials
I tried using the domain credentials that work on a Windows 10 PC
I created a local user and assigned that user ownership of the share

I ran the command:
# pvesm cifsscan 192.168.2.230 --username cifsuser --password --domain TAZNET2
Enter Password: **********
unexpected status: NT_STATUS_ACCESS_DENIED

Edit:
# smbclient //192.168.2.230/pve_storage -d 0 -m smb3 -U cifsuser -c 'echo 1 0'
Enter WORKGROUP\cifsuser's password:
session setup failed: NT_STATUS_LOGON_FAILURE

# pvesm cifsscan 192.168.2.230
unexpected status: NT_STATUS_ACCESS_DENIED

It seems that either the user or the dataset has some kind of permission set up incorrectly. If anyone can help me
straighten this out, it would be great!

 

[aaron]

Have you checked if the user also has the permissions for the CIFS share? It has been a while, but from what I remember, you need to configure it in at least two places (dataset and share) in TrueNAS.

 

[Sprinterfreak]

I have a similar problem, being unable to connect to samba/cifs shares.
From what I see in smbd's log on the storage side, pvesm always tries to connect as user nobody regardless of what --username is supplied to cifsscan. This doesn't look right.

create storage failed: storage 'backup' is not online (500)

On the other hand cifsscan is able to list shares, only if they are publicly browsable. But still not able to connect.

There was at least recent activity in CIFSPlugin.pm related to set_cifs_credentials, now passing %sensitive . Maybe this screwed somthing up.
https://git.proxmox.com/?p=pve-storage.git;a=commitdiff;h=02f43ab4a82d00775e7a885a982c387436dce32b

 

[sgt_jamez]

Using a TrueNAS local user that had full read/write access did not work. However what did work was a reboot (that cleared a half-completed but failed mount) and then adding the CIFS share via gui using a a domain user/pwd that had full access and the domain entry filled in. Ok cool. Fine point details.

I was able to get some of the commands above to work with the correct formatting. I didn't document what worked. I was way down the rabbit hole and getting fried.

My follow-up question then, is it even possible to mount a CIFS share using a TrueNAS local user/pwd?

I know it's not apples to apples, but I had a Raspberry Pi set up to mount a CIFS share using a local user in my Synology. This was done in fstab on the rPi.

On Promox, cat /etc/fstab does not list the mount for the TrueNAS share. Is there a way I can see how this GUI config looks as a command? I thought the GUI entry would be passed down to fstab but that's not the case.

 

[aaron]

My follow-up question then, is it even possible to mount a CIFS share using a TrueNAS local user/pwd?

I gave it a try, fresh installed TrueNAS.
After installation, the SMB service is not yet running:

# pvesm cifsscan 192.168.26.4
#

Starting the SMB service in TrueNAS:

# pvesm cifsscan 192.168.26.4
unexpected status: NT_STATUS_ACCESS_DENIED

Created a new dataset "share" with SMB share options (case insensitive) and adding a share with default settings:

# pvesm cifsscan 192.168.26.4
unexpected status: NT_STATUS_ACCESS_DENIED

Changing the share settings and allowing guest access:

# pvesm cifsscan 192.168.26.4
share

Removing guest access results again in the NT_STATUS_ACCESS_DENIED error.

Adding a new user "test":

root@nola:~# pvesm cifsscan 192.168.26.4 --username test --password 123
share

Trying to add the share as storage:

# pvesm add cifs sharetest --server 192.168.26.4 --share share --username test --password 123
mount error(13): Permission denied

Changing the permissions of the dataset by applying the user "test" to it, making it the owner, and adding the storage works. Of course you could also set the group/other permissions loose enough for it to work.

On Promox, cat /etc/fstab does not list the mount for the TrueNAS share. Is there a way I can see how this GUI config looks as a command? I thought the GUI entry would be passed down to fstab but that's not the case.

No, network storages configured directly as a Proxmox VE storage will be mounted by Proxmox VE tooling and not the fstab or systemd mount units.
If Proxmox VE mounts a share, it is always mounted in /mnt/pve/<storage name>.

If you do have a hanging mount you can try to unmount it on the CLI, sometimes with the force and lazy parameters:

umount -f -l /mnt/pve/<my storage>

The next time the pvestatd daemon tries to access the storage, it will try to mount it again. If you don't want that you will have to uncheck the "Enable" checkbox if you edit the storage in the GUI.

 

[Tmanok]

I have connected numerous TrueNAS and FreeNAS systems as NFS and CIFS storage to proxmox, each time was a pain in the neck.

Quintuple check your dataset permissions and be super effing sure that your user really does have access. Additionally make sure that your share settings have been configured correctly. Unfortunately I only have NFS sharing active right now so unless you'd like me to share my NFS configuration with you, I can't guide you 100%.

It almost always boils down to a missed permission, try to map the drive from another machine such as a VM and also consider using the cli on your TrueNAS server to su - user and test the permissions.

Tmanok

 

[Monstrous1704]

So what happened for me, I have unRAID, I have permissions setup, but what I noticed was that the template folder proxmox creates in the share was under user `nobody` which has no permissions, despite being created by proxmox.

I updated the owners for the folder tree to the correct user and everything started working correctly. Not sure where the bug lies, but as it happens with unraid/truenas, guessing a combination of implementations