SOLVED FreeNAS-11.3-U5 --> TrueNAS CORE 12.0-U4: Can't access to my SMB shares as "root" anymore... Can't access at all actually!

[PépéDansLesOrties]

Hi morganL,

isn't that what you are removing?

Well, not exactly. I'm not trying to remove "root", I'm just trying to connect with a different user since "root" is forbidden...
Theoretically, the ACL acts as a hierarchy, isn't it? So if the boss let the manager and the employees access to his data, the employees will indeed be able to access to his data, right?
This way, the ACL of the new dataset includes:
- "root", even if I can't connect with, as the @owner;
- @group & group: klf, my new user primary group;
- user: klf, THE new user with which I should be authorized to connect through samba.

However, despite the theory, I'm that desperate I tested your suggested ACL without "root": I can see FreeNAS on my network but I immediately got the pop-up error message "Windows can't access to...", I can't even see the mounting points.

If I re-modify the ACL as in the screenshots ("root" as @owner, klf as @group, group & user), in both Windows 10 & SparkyLinux:
- I can see FreeNAS in my network;
- I can connect with klf, my new user;
- I can see the mounting points;
BUT I can't access to them:
--> Windows pops up the error message;
--> SparkyLinux pops up again a connection window which expects the good answer from me: neither klf nor "root" seems to be the right one...

 

[PépéDansLesOrties]

+
Note that I got 4 pools. 2 from a previous DIY FreeNAS, 2 created on my current TrueNAS Mini XL+, with the same config than the 2 first, it means with "root" only on their dataset.
--> I STILL CAN access to these 2 last pools, on both Windows 10 & SparkyLinux, even though "root" is supposedly forbidden and deactivated...
--> There is obviously something really wrong, but what? And I can't even fully compare the pools since "modify permissions" is gray 'cause it's "root", everything else is the same...
Nightmare's still on...

 

[morganL]

4 pools not 4 datasets/shares? I
assume you have rebooted to see if issue is temporary?

It seems like you should be able to "modify permissions" ... Can you on the 2 last pools?

 

[PépéDansLesOrties]

4 pools not 4 datasets/shares?

Yes: 4 pools, 1 pool = 1 "root" dataset = 1 mounting point in SMB shares.
Until then, I was able to access to them through samba with "root", not anymore (forbidden by new feature).
In order to access to my data again, I created a new user with recursive full control, created a new dataset linked to that new user on my first pool (testing), and finally created a new mount point for this dataset. Cf screenshots.

I assume you have rebooted to see if issue is temporary?

Yep, I did reboot the NAS and the PCs trying to access to it. Changes can be seen, issue remains.

It seems like you should be able to "modify permissions" ... Can you on the 2 last pools?

Nope, I can't because, like the others actually, they are "root", and so I can't neither see nor modify permissions, it's gray. The only permissions I can see and edit are the ones of the new dataset I created in order to bypass the now forbidden "root" access.

I did attach screenshots a bit earlier: you will able to see:
- my 4 pools, each one with "root" dataset only, but the one on which I created a new empty dataset from which I'm supposed to recursively access to the root dataset;
- the new user config;
- the ACL for the new dataset with recursive full control;
- the samba shares
- the SMB service config (with forced SMB1)

 

[morganL]

I suspect (don't know) the problem might be that you are trying to fix the "root" issue with software version that doesn't accept "root" as a user. This operating mode was not designed for or tested. You are hence getting permission issues.

The 12.0 release notes have this warning: https://www.truenas.com/docs/releasenotes/core/12.0u4/

If this is the case, the solution would be to go back to FreeNAS 11.3-U5..... as long as the pool settings have not changed. From there, change all the settings so that root is not a user or owner of the SMB shares.

@anodos Can you recommend any better approach?

 

[PépéDansLesOrties]

This operating mode was not designed for or tested

That's what I have been first worried about, MorganL. But it seems way too incredible that devs didn't think a bit more about it and could ruin a config of many years just like that... Then it's kind of strange that samba root access is now forbidden for security reasons, but that you can create a user with full permissions including sudo and an ACL with recursive full control... But you're maybe right, I just hope you're not ...

If this is the case, the solution would be to go back to FreeNAS 11.3-U5

But how? 'Cause in TrueNAS, you can't choose your "train" anymore (another new feature I guess)...
I kept the config .tar before upgrade, it might help, but how to downgrade? Then, pools have been updated (at least flags), will they be usable?

@anodos Can you recommend any better approach?

I would indeed appreciate @anodos give us (me) his point of view. Since what we (thanks @X3n0n ) are doing seems theorecally right, I lean towards a tiny error, a tiny detail I miss that blocks everything.
It's been a week now, I'm somehow desperate but patient. I can delete the new user, the new dataset, the new mounting point, I can attach screenshots, I can start again from scratch. I just want to get back my data accessible and my NAS functional.

Anyway, thanks for your time and support, MorganL, it's very appreciated.

 

[morganL]

@PépéDansLesOrties
The SAMBA security change was at direction of Samba... it was to avoid backdoor access to the systems which could be used for ransomware. It's a difficult decision to make these changes, but data security has to be the priority.

Unfortunately for you, we expected users to remove root ownership before upgrading to 12.0 We have to see what fixes are possible after upgrade. Your symptoms seem to be indicating there is an issue.

Anything done via sudo is not via TrueNAS middleware. We don't control that.

If pools have been updated then going back to 11.3 might not be possible.
If you do go back, it would be by creating a new boot drive Could be a USB stick for temporary use).
Lets wait for a real expert before you do anything dramatic.

 

[Kris Moore]

Just to follow-up here. I had a chance to look closer at this issue and talk to the engineers.

Typically the process of migrating from root -> <some other user> is pretty straight forward:

1. Create new user via the UI
2. Via the System -> Shell, do a "chown -R <username>:<username> /mnt/tank/<dataset>
3. Re-create share, using the username as the default owner.

That should be it, unless you have some other funky permissions to handle.

 

[X3n0n]

I don't understand why you have to remove root from owning the dataset.
I mean, it is a possibility if you want to but I don't see why it's mandatory

I'm on 12 U4, my dataset is owned by root/wheel and I gave access to my main user with ACL and it works fine via Samba.

Dataset owned by root

Code:

Core% ls -la /mnt/data-pool/
total 108
drwxr-xr-x    9 root  wheel    9 Jun  4 14:34 .
drwxr-xr-x    4 root  wheel  192 Jun 10 20:39 ..
drwxrwx---+   6 root  wheel    6 Jun  4 16:34 App-Backup
drwxrwx--x+   4 root  wheel    4 Jun 23 15:12 CoreMachine
drwxrwx---+  12 root  wheel   17 Jun 14 18:04 Documents

Inner data owned by my user :

Code:

Core% ls -la /mnt/data-pool/Documents/
total 3685
drwxrwx---+ 12 root   wheel       17 Jun 14 18:04 .
drwxr-xr-x   9 root   wheel        9 Jun  4 14:34 ..
-rwxrwx---+  1 xenon  wheel     6148 Jun 14 18:04 .DS_Store
drwxrwx---+ 19 xenon  wheel       56 Jun 20 18:35 00 - Administratif
drwxrwx---+  6 xenon  wheel       28 Dec 10  2020 01 - LEZ IN ART
drwxrwx---+  5 xenon  wheel       14 May 31  2020 02 - Voyages
drwxrwx---+  2 xenon  wheel        3 Apr 23  2017 03 - Notes de frais

My guess is that something is misconfigured/not visible via the GUI and blocking Pépé from accessing his data.

The only difference between Pépé config and mine is at the SMB service level, I don't have an administration group set.

 

[PépéDansLesOrties]

Hi @Kris Moore

1. Create new user via the UI
2. Via the System -> Shell, do a "chown -R <username>:<username> /mnt/tank/<dataset>
3. Re-create share, using the username as the default owner.

Long day for me, I will try this tomorrow morning... Do you confirm I won't put my data in jeopardy? If it doesn't work, will I be able to put back my dataset in "root" by the same procedure?

Hi @X3n0n

My guess is that something is misconfigured/not visible via the GUI and blocking Pépé from accessing his data

Still my guess too, actually.
A few years ago, on my first FreeNAS, I was stuck (already) with samba 'cause SMB1 was deactivated, while, for some bad and still current reasons, Thunar (XFCE) ignores smb.conf and so manages nativaly SMB1 only (I know, I konw, it's lame about security)

@Kris Moore @X3n0n Meanwhile, have a nice day/night!

 

[PépéDansLesOrties]

Hi everybody!
So, before trying to apply blindly @Kris Moore 's procedure, I tried to dig and test a bit more...
-
First, about having still access to 2 pools while I shoud not, I discovered this weirdness:
--> If I pretend to create a new SMB share, I can see that only my 2 blocked pools are ACL flagged:

--> But if I go back in SMB shares to have details about them, my 4 pools do have well ACL:
KLF--01, blocked, ACL flagged:

KLF--03, oddly still accessible, not ACL flagged:

--> As you can see, details show the same config with ACL activated, and as a matter of fact, the 4 pools are "root" with (again) the same config too.
Does it mean the issue is the ACL, as @X3n0n thinks from the begining? (Ain't it a security breach -what an irony!-?)
-
Then, about the theoretical disagreement between @X3n0n & @Kris Moore , I wonder if the issue is not in the ACL profile of the new dataset "NR--01": what if I just not mention the "root" affliation at all? I test, and come back...

 

[PépéDansLesOrties]

Back. So here is what I tested:
An user with full permissions:

And an ACL not related to/not mentioning "root":

Reboot NAS & PCs
--> Same reaction:
On both Windows 10 and SparkyLinux (Thunar & XFCE), when I want to discover FreeNAS, pop-up connection window --> enter "klf" + password: I can see all the mount points, but when I want to access to "NR--01" (dataset linked to klf), I got no permissions, neither for the others but "KLF--03" & "KLF--04" (which have ACL but no ACL flags, cf. previous post) are still accessible, without asking anything moreover.
--> I think it leads to think that something's wrong/incomplete/wicked with the ACL since it let me discover FreeNAS and see all the mount points with "klf" but then restrain the access...

If I got no other choice, I'll try the @Kris Moore 's procedure, but I'm usually reluctant to apply something I don't really understand, and fact is I'm not good enough to understand what he suggests me to do...

 

[PépéDansLesOrties]

Final entry:
@anodos used my debug report to reply this:

Code:

Mountpoint ACL:
# file: /mnt/KLF--02
# owner: root
# group: wheel
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:--------------:fd-----:allow
debug finished in 0 seconds for KLF--02

then, in shell:

Code:

ACL on this path prevents anyone other than root from accessing data.
Run this command:
 setfacl -m everyone@:rxaRc::allow /mnt/KLF--02

It actually allowed me to access my non-root child dataset (NR--01) linked to my non-root user (klf), but still not to the root dataset (KLF--01)...
It allowed me to bypass the issue, and it's great, but issue from ACL remains. Whatever...
So I began a very long process:
--> Web UI > Services > Activate SSH
--> Console >

Code:

ssh root@freenas

--> copy, verify then remove, bit by bit, directories from root dataset (KLF--01) to non-root child dataset (NR--01) >

Code:

ls /mnt/'root dataset'
cp -r -v /mnt/'root dataset'/'directory 01' /mnt/'root dataset'/'non-root child dataset'

> -v is very useful and reassuring to give an idea of copy progression
> verify copy went actually fine, then:

Code:

rm -r -v /mnt/'root dataset'/'directory 01'

> -v for same reasons
> ditto for directory 02, 03, etc.
Then, I did create a child dataset (NR--02) linked to my non-root user (klf) on my second pool (KLF--02), ditto for my 2 other pools.
I copied, verified, removed directories from root dataset to non-root child dataset for each pool.
Then, I delete the 4 mount points of my root datasets (KLF--01, etc.) in SMB shares, and configure only the non-root child datasets (NR--01, etc.) mount points.
It's been long, but done.
I'd like to thank you all again: @X3n0n , @morganL , @Kris Moore & @anodos for your interest and your time.
I've been very chatty and I'm sorry about that 'cause it's quite unusual in IT threads, but when you're neither professional nor native english-speaker, details and repetition are helpful!
Best regards!
Pépé.