I’d greatly appreciate assistance on the following issue having spent 6+ hrs unsuccessfully searching for an answer.
I’m transitioning from CORE to SCALE. I recently physically built a new SCALE server, physically transferred my HDDs from the old CORE system to SCALE, and easily was able to import the dataset “Volume” under the latest Dragonfish.
My issue is that I am unable to share this dataset by SMB. I encounter a validation error stating that there is an ACL type mismatch with several child mountpoints in a root directory “.system” (the error is listed below). I am able to share “Volume” by NFS without issues. I wish to share the root directory which I’ve heard discussed as discouraged but has worked well for me for 10+ years.
I cleared the ACL list, which didn’t help. I hesitantly tried to delete the “.system” directory, but these files are reported to be in use. I cannot access dataset ACL lists by any GUI, as there is no “edit” box to check under permissions for the dataset. I’m now stuck.
Two questions:
How do I share this dataset by SMB?
Can I delete the “.system” directory, which contains no data of relevance to me and appears to be the source of the problem? Is this a holdover from FreeNAS days (the dataset is about 10 years old)? As a corollary, can I also delete the “.freenas” directory and the .sync.ffs_db file also found in the root folder?
Thanks in advance for any thoughts. The TrueNAS community has been helpful to me in the past and appreciate that ixSystems provides this valuable resource to the enthusiast community.
Error encountered is
VALIDATION : [EINVAL] sharingsmb_create.path_local: ACL type mismatch with child mountpoint at /mnt/Volume/.system: Volume - NFSV4, Volume/.system - OFF [EINVAL] sharingsmb_create.path_local: ACL type mismatch with child mountpoint at /mnt/Volume/.system/syslog-eab18b758b91471d95803a91d80bfcda: Volume - NFSV4, Volume/.system/syslog-eab18b758b91471d95803a91d80bfcda - OFF [EINVAL] sharingsmb_create.path_local: ACL type mismatch with child mountpoint at /mnt/Volume/.system/services: Volume - NFSV4, Volume/.system/services - OFF [EINVAL] sharingsmb_create.path_local: ACL type mismatch with child mountpoint at /mnt/Volume/.system/webui: Volume - NFSV4, Volume/.system/webui - OFF [EINVAL] sharingsmb_create.path_local: ACL type mismatch with child mountpoint at /mnt/Volume/.system/rrd-eab18b758b91471d95803a91d80bfcda: Volume - NFSV4, Volume/.system/rrd-eab18b758b91471d95803a91d80bfcda - OFF [EINVAL] sharingsmb_create.path_local: ACL type mismatch with child mountpoint at /mnt/Volume/.system/samba4: Volume - NFSV4, Volume/.system/samba4 - OFF [EINVAL] sharingsmb_create.path_local: ACL type mismatch with child mountpoint at /mnt/Volume/.system/cores: Volume - NFSV4, Volume/.system/cores - OFF [EINVAL] sharingsmb_create.path_local: ACL type mismatch with child mountpoint at /mnt/Volume/.system/configs-eab18b758b91471d95803a91d80bfcda: Volume - NFSV4, Volume/.system/configs-eab18b758b91471d95803a91d80bfcda - OFF
You should Report A Bug and upload all the details. It’s a bit strange to get two posts like this. You can do that in forum at link at top or inside TrueNAS (Feedback)
Your VDEV / pool setup is strange being 20 wide.
I linked the other thread so any other member was aware.
I appreciate the suggestions, SmallBarky and awalkerix.
Under “Edit Dataset”, ACL Type i= SMB/NFSv4 and is grayed out and cannot be changed. ACL Mode = Passthrough and is also grayed out.
As for fixing the SMB permissions, I’m unable to create an SMB share using any of the “Purpose” presets (such as default share parameters, basic time machine share, etc). I’m not sure how to fix permissions on a share that I can’t create.
I do have a question: when I select my path (/mnt/Volume) under “Add SMB” when trying to create this share, an option pops up with a folder icon containing a plus sign that says “Create Dataset”. Should I? My understanding is that since I already have a dataset and just want to share it, I should not create another.
I appreciate both suggestions and would invite others, as I’m still unable to share via SMB. Thanks much.
SmallBarky and awalkerix, thank you both for your efforts.
I am including a screenshot of my dataset and details for “Volume”.
“pool” is a single 4TB NVME used for apps
“Volume” is a 20 drive 16TB HDD RAIDZ2 used for long term storage
I will look again at the SMB section of the scale docs and report back if anything aided in solving my issue. Until then, other suggestions are appreciated–particularly if anyone knows if I can (and how I can) delete the problematic .system folder in my root directory which is interfering with me being able to share this dataset.
Correct. I should be able to create a share inside the volume set. However, when I specify the /mnt/Volume directory to share by SMB and click “Save” on this screen, I get a “Validation” error because of ACL errors with a “.system” directory that FreeNAS created in 2014 that I can’t delete (files in use).
And this is the problem they are trying to point out for you.
You’re trying to share the whole pool called “Volume”, that’s a no-no.
Instead, go to Datasets, select your pool called “Volume”, click Add Dataset in the upper right, give it a name and pick a preset, SMB is a good start.
When it has been created you go to “Add SMB” with that as the path instead, so for example the path could be /mnt/Volume/MyNewSMBdataset.
Neofusion, your clear explanation was of great help and allowed me to establish an SMB share. As you suggested, under Datasets I selected /mnt/Volume, clicked Add Dataset choosing the name “tank” and chose SMB as the preset. This then created an empty SMB share /mnt/Volume/tank. Under the CLI I was then able to:
mv /mnt/Volume/dir1 /mnt/Volume/tank
and could then access the contents of dir1 via SMB.
I should point out that I am still unable to delete (or understand the origin of) /mnt/Volume/.system, but I can certainly live with this as the space requirements are very low.
I do remain a bit confused why I can’t share the entirety of a pool rather than a directory of the pool as I have done so in the past, but I am not arguing the point. This works.
Fingers crossed there are no issues in doing a mv command on 100TB of 10+ year old data to move /mnt/Volume/* to /mnt/Volume/tank/* (no reason it shouldn’t work, but stress testing like that tends to surface bugs).
I’m marking this problem solved, and many thanks to SmallBarky, awalkerix, and neofusion for taking the time to assist.
.system is hidden system related files.
Root and Admin don’t have SMB sharing. They were allowed in the past. I don’t know if this is one reason you had problems.
