Permissions not applying - SMB share on Ubuntu 18.04

[Mudslinger]

I have been working on my media server the last couple of days but i can't seem to wrap my head around the permissions. For some reason, i don't have permission to write.

I have been running freenas for several years now (current build: FreeNAS-11.1-U7), it has 2 users, my personal account and a 'plex' account and a group called 'thuisgroep'. Both users are part of this group.
The dataset has the PERMISSION_TYPE "windows". Most computers are windows based, with some a few unix based systems. the OWNER and GROUP have read, write and execute permissions. And i'm sharing it via the SMB protocol.
In Windows i have no trouble accessing the share nor do i have issues with permissions. Everything works, i can add, remove, change, create etc.

The mediaserver runs on Ubuntu Server 18.04 which runs things like Plex. So adding the share to my mediaserver is required for plex to see all the content. For now its a fresh install, doesn't have a firewall enabled. The only things installed are updates, ssh, cifs-utils and docker.

I had a previous server running ubuntu 16.04 on which everything worked, so i simply copied the entries in /etc/fstab.
This is one of the entries:
//192.168.1.100/storage/music /mnt/Music/ cifs iocharset=utf8,credentials=/home/user/.smbcredentials,sec=ntlmssp 0 0
All i needed to do was to make sure the UID and GID on ubuntu matches those on freenas. (and ofcourse create the directory in /mnt and give it permissions).

Once i matched those, i mounted to share with sudo mount -a and the share is mounted.
I can mount the share without a hitch, i can mount it with both my own account as well as 'plex'. the problem i have is that the permissions in Ubuntu look like this:

Code:

drwxrwxr-x  3  775 root 4096 Jun  8 16:59 ./
drwxr-xr-x 23 root root 4096 Jun  8 16:22 ../
drwxr-xr-x  2 root root    0 Jun  9 10:41 test/

As you probably can guess, i don't have any permissions to read or write in it, as only ROOT can.
To give you a perspective on how the permissions are on Freenas:

Code:

drwxrwx---+    3 plex  thuisgroep      7 Jun  9 10:41 Test/

these are the permission on the directory when the share is not mounted:

Code:

drwxrwxr-x  2 plex thuisgroep 4096 Jun  8 16:59 test/

I did some searching on the internet and what others are referring to is to add the UID and GID in the options of the Cifs share. So i added that as follow:
//192.168.1.100/storage/music /mnt/Music/ cifs iocharset=utf8,credentials=/home/user/.smbcredentials,uid=1002,gid=1001,sec=ntlmssp 0 0
now the permissions "look" correct:

Code:

drwxr-xr-x  2 plex thuisgroep    0 Jun  9 10:41 test/

at least the owners look correct, the permissions themselves, don't. However, i can write to the directory as user 'plex' (i mean, if i login to ubuntu as plex, i can write files in that share). Which makes sense as PLEX is the owner.
But my personal account cant write in it. Which, from the last permissions listed, makes sense too because 'thuisgroep' only has read permissions. But according to freenas, the group 'thuisgroep' should have write permissions as well.

It seems like freenas is not providing the permissions information to ubuntu for some strange reason? When i was running ubuntu 16.04, my freenas version was 9.x (can't recall exactly which version, sorry). I didn't need to specify UID or GID nor did i need to add file_mode or dir_mode to the cifs share options.

The biggest issue i have is that the permissions in ubuntu don't match those of freenas. I can overwrite that in ubuntu (with file_mode and dir_mode) but it doesn't change anything on Freenas'-side. it's more of a visual-correction than the real permissions.

what am i doing wrong? How can ubuntu see the permissions that are specified in freenas? (or what changed since freenas 9.x that it wont work anymore).

 

[KrisBee]

AFAICT what you're describing in Ubuntu 18 is the expected behaviour when mounting a FreeNAS 11.1-7U SMB share with default "windows" settings - dataset perms "windows type" and "default perms" on the SMB share definition.

Both fstab and CLI mounts make use of the linux kernel CIFS VFS module as described in "man mount.cifs". IIRC, your "personal account" will only have write access to the share if your mount command uses your "personal account" credentials, uid of "personal account" and gid of "thuisgroep".

 

[Mudslinger]

I get that feeling as well, that it is "expected behavior". No matter what i tried it seemed to result in manual adjustments.
So has changed in the last year or so? cause i never had to do that in 16.04 and freenas 9.x. i could write as both users.
Any idea if this is because of samba (changes) or does does have to do with something else entirely?

Honestly, what bugs me the most is that i have to log in to the freenas server just to see whether the permissions on the files and folders are correct (as sometimes programs like plex have a tendency to have wrong permissions from time to time).

 

[KrisBee]

Did you enforce "default perms" on your windows shares in FN9 and also select "windows" share type on your shared datasets? If so, was the same extend ACL created on the dataset as it is now in FN11?

There certainly have been changes to FN. but fundamentally you have an imperfect mapping of the simple UNIX style perms in Linux onto the more complex NFSv4 ACL model supported by FreeNAS, hence the need to view the data on your FreeNAS server or via Windows to get the correct info.

 

[Mudslinger]

At the time of FN9 i mostly had the settings on default as i was still relatively new to it. I know i choose the 'windows' share type (duo to windows-clients), not sure if the 'default permissions' was selected. It's enabled by default right? so i probably had it enabled back then as well.

I don't quite understand what you mean by "you have an imperfect mapping of the simple UNIX style perms in Linux onto the more complex NFSv4 ACL model supported by FreeNAS". You mean it's imperfect because i map a SMB-share in Ubuntu? You say "imperfect", is there a more "perfect" way (or probably a better question: is there a better way to mount such a share in Ubuntu)?

I'm just curious about all this and looking for possible options. i like to make things work and in order to do so i need to understand it first. Hence the questions. I was looking at the NFS-share, but from what i can find, if i were to make a 2nd share to my dataset based on NFS, this would complicate things with the SMB-share, right? As both shares would access the same data which could result in files being inaccessible.
Nor is it possible to change the existing share to an NFS, correct?

 

[KrisBee]

I've forgotten how the defaults worked in FN9, but the question really is did you end up with the same extended ACL on the shared dataset as you do now in Fn11 and the correct values for the aclmode & aclinherit properties?

NFSv4 ACL & Windows ACL are almost the same, whereas you could argue the standard linux perms is only a subset of this. For example, how do you represent "everyone" perms in Linux? In NFSv4 ACL everyone means literally that, owner+group+other. As we don't have a perfect or near perfect match between NFSv4 ACL & linux perm models, it must be imperfect.

Clearly, FreeNAS SAMBA & SMB share configs are primarily designed to work with Windows. If you were accessing SMB shares exclusively from Linux you might use a different config to the defaults, but as soon as you want to share the same data in both Windows & Linux via SMB it's a compromise.

You'll probably read people saying they accessed the same data via SMB & NFS at the same time without a problem, others say this could only work safely if one protocol was restricted to read-only. I wouldn't do it at all.

You can't change an existing SMB to NFS, but you can delete one share type and create a new share of another type on your dataset. In the case of deleting a SMB share, before creating the NFS share you would have to set the dataset share type in unix. But you would need to check an extended windows type ACL has not be left on the dataset (or any files/dir beneath it) and remove these via the CLI if necessary with the appropraite setfacl command. Then in the UI set the unix perms want, using recursive if necessary.

 

[Mudslinger]

Thanks for the explanations KrisBee, i get what you mean and it's been helpful.

My dataset and share didn't change by my hands, i simply upgraded the versions. Though i can image the changes the newer versions bring might have changed some underlying details about my dataset or share. In that regard i don't know whether my share has the correct values of aclmode and aclinherit. I might still have a backup somewhere from 9.x, so i could possible compare it. But that's for another day to be honest, as i need to install a new Freenas server for it.

When i first made the share i was confronted with the fact that SMB was meant for windows and wasn't particularly meant for unix. In the end i did manage to mount, access and change things on the share. This is partially why it bothers me so much, as in "it used to work, why not now" etc. But i digress.

I rather avoid possible problems and agree, i rather not use a 2nd share, so i'll forgo that option. Same for changing the permissions. I'm to inexperienced in all honesty to change this without worry. I need to do some digging on that before i consider it.

All-in-all, it was informative, thanks for that. for now i have mounted it with the needed parameters in order to access and change the data, so everything works, that's the most important thing right now.