Creating a dataset and share for cross-system development use

,

Thought I’d posted this last night, but it doesn’t show up under “my posts”.

I want a share to be mounted on various systems where I do development – windows, Linux (including virtuals), Raspberry Pi are the current examples. This lets me keep my work together (and back it up as part of the overall NAS backup), and it lets me do things like edit the files on one system but test them on another (useful for very small systems, where the editor strains it). Most of these projects include git repos in the share.

I had this under CORE; the transition to SCALE/CE (the switch to Linux) broke my existing example, and I haven’t been able to fix it.

Elsewhere, I’m having trouble with an existing share that I’m trying to use for this, where the permissions don’t work – created files are all executable, and while chmod returns success, it doesn’t actually change them (to 0600, say, or 0660).

Well, I’ve tried creating from scratch a new top-level dataset, and sharing it, for this purpose – and I get the exact same weird behavior. Which is that newly created files all have execution permission set, and chmod won’t change it.

This seems like an extremely basic, I would expect common, use case! So it can’t possibly really not work this blatantly. So I’m doing something stupid. Can we figure out what? Either how to create a new such share, or how to fix an existing one?

Running TrueNAS community edition 25.10.6. Latest test dataset created as multiprotocol share, owned by user ddb. Shared via smb as multi-protocol share.

I had seen an earlier post, which you apparently deleted.
A screenshot of your permission settings would help.

chmod not working might be a NFSv3 vs. NFSv4 issue.
Why “multiprotocol” since it seems that you only access the share through SMB and not NFS?

Trying to guess what profile was best adapted to multi-environment work. Should I go back to default? I think I started, before, with default, and started playing around when that didn’t work. (One of the problems of these big “doesn’t work at all” situations; so many things to try, and keep track of having tried.)

I can’t find what’s forcing created file protections to 755, or what’s causing chmod to not work (silently; it returns success). In particular, it’s not the SMB parameters create mask or force create mode.

This seems like the most basic, broadly useful kind of share; why is it so hard to create? Shouldn’t this be the default, and you could do other things if you had special needs?

The new test dataset is /mnt/zpdb/ddbshare3

The dataset permissions show in the GUI as

From the command-line on the server, the ddbshare3 directory looks like

ddb@fsfs:/mnt/zpdb$ ls -l /mnt/zpdb/ddbshare3/
total 1
-rw-rw---- 1 ddb ddb 7 Aug 15 12:16 test.txt
ddb@fsfs:/mnt/zpdb$ nfs4xdr_getfacl /mnt/zpdb/ddbshare3/
# File: /mnt/zpdb/ddbshare3/
# owner: 1001
# group: 1001
# mode: 0o40755
# trivial_acl: true
# ACL flags: auto-inherit:
            owner@:rwxpD-aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow

On the (vm) linux box I’m mounting it on, the share shows as:

//fsfs.local/ddbshare3 on /home/ddb/shr3 type cifs (rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,username=ddb,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.1.205,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1)

On the vm, the mounted share looks like:

ddb@fsfsdev3:~
$ ls -ld shr3
drwxr-xr-x 2 ddb ddb 0 Aug 15 12:16 shr3
ddb@fsfsdev3:~
$ getfacl shr3
# file: shr3
# owner: ddb
# group: ddb
user::rwx
group::r-x
other::r-x

Creating a text file creates it executable, and I can’t change it:

ddb@fsfsdev3:~
$ echo TESTING > shr3/test.txt
ddb@fsfsdev3:~
$ ls -l shr3/test.txt
-rwxr-xr-x 1 ddb ddb 8 Aug 15 18:37 shr3/test.txt
ddb@fsfsdev3:~
$ chmod 600 shr3/test.txt
ddb@fsfsdev3:~
$ ls -l shr3/test.txt
-rwxr-xr-x 1 ddb ddb 8 Aug 15 18:37 shr3/test.txt

Obvious anomalies include that SMB3 unix extension don’t seem to be activated.

Switching it to a default share, restarting the SMB service, and remounting the share doesn’t change the behavior of chmod.

It is a most basic kind of share because it is single protocol as you use it; “multiprotocol” is for a share that is accessed both through SMB and NFS, and that brings in complexeties and subtleties.
chmod 600 is old-style NFSv3 but your share has the more complex NFSv4 ACLs. @awalkerix might come and explain what happens with chmod commands in this context.

I suggest creating a new share that is SMB-only, and see whether you can get the expected behaviour starting from that.

Looking at how the mount on the virtual actually plays out, I think the root cause is that the mount is happening in “nounix” mode (no SMB extensions).

That seems to be the TrueNAS CE default.

Converting the share to the Legacy profile, and adding SMB3 unix extensions = yes as an additional SMB parameter, seems very hopeful.

I have done this.

ddb@fsfs:/mnt/zpdb$ ddb@fsfs:/mnt/zpdb$ midclt call sharing.smb.query '[["id","=",17]]' | jq '.[0] | {id,name,path,purpose,options}'  {
  "id": 17,
  "name": "ddbshare3",
  "path": "/mnt/zpdb/ddbshare3",
  "purpose": "LEGACY_SHARE",
  "options": {
    "recyclebin": false,
    "path_suffix": null,
    "hostsallow": [],
    "hostsdeny": [],
    "guestok": false,
    "streams": true,
    "durablehandle": true,
    "shadowcopy": true,
    "fsrvp": false,
    "home": false,
    "acl": true,
    "afp": false,
    "timemachine": false,
    "timemachine_quota": 0,
    "aapl_name_mangling": false,
    "vuid": "4fe06d00-1309-45a2-8f52-b2468ce51571",
    "auxsmbconf": "smb3 unix extensions = yes"
  }
}

The purpose correctly shows as Legacy Share in the GUI, and the aux smb configuration line shows in the GUI.

Restarting the service with

ddb@fsfs:/mnt/zpdb$ midclt call service.restart cifs
True

seems to succeed.

But I can’t get the mount to come up in any way but “nounix”. Made sure the mount was inactive when the cifs service was restarted, then re-mounted, all that sort of thing. Always comes up nounix. (I thought I had gotten a previous share to mount in unix mode, over under the old thread tracking back from the failed share instead of starting from scratch; but that test share, ddbshare2, also mounts in nounix mode when tested today.)

The log file /var/log/samba4/log.smbd shows I’m running Samba version 4.22.10-truenas. I’m running Truenas CE 25.10.6.

I suppose it’s worth doing, it’s not that much trouble. There are so many layers between me and the software that it’s hard to be at all confident anything is doing what I think I’m telling it to do. Okay, here comes ddbshare4!

Nope, the mount comes up nounix even on a brand-new share that’s never been shared as anything but SMB, and was never multi-protocol. (Created as default, then immediately switched to legacy and added the additional SMB parameter for unix extensions before it was ever mounted.)

I wonder, is there any point to trying to step forward to the “early adopter” update profile? I think that gets the version of Samba that defaults to supporting Unix Extensions.

What’s the risk? Obviously some. I’m not heavily loaded, I’m not mission-critical to making a living, I have 3 separate backup sets, one off-site. (But having to fall back to a backup set would take days and be a royal pain.)

Okay, I’ve spent a lot of time (partly because I’ve been working in fits and starts rather than with real focus) digging into this, both using suggestions here and things I found elsewhere.

Here’s my conclusion:

  1. The stable release train, TrueNAS SCALE V25, doesn’t really provide any way to do this. (I’ve managed to turn on SMB3 Unix Extensions, but they don’t help, in that branch.) This is a regression from TrueNAS CORE, in my experience.

  2. The early-adopter train, V26 (which has a considerably updated Samba package) works fine if I turn on SMB3 Unix Extensions (the same technique works as in V25). (I worked specifically with V26 Beta 3.)

(Going back to V25 and replicating what worked in V26 does NOT work, it’s not just that I learned how to do it better along the way. I was hoping, but no luck.)

(The switch from BSD, with jails, to Linux, where my option for a dev environment on my server is full virtual machines which do not have direct access to the ZFS datasets, is the underlying cause of my problem; one group of things I’m now having to do on a virtual machine, accessing data via some network protocol, I used to just do locally in a jail.)

I was all ready to file a bug report, but since V26 doesn’t have the problem, it’s either already fixed (if somehow a local problem), or something already fixed over in Samba (more likely I think, and there’s been activity in that area in the Samba project between the version in V25 and the version in V26 Beta 3).

(My final testing environment was virtual machines; I did not put V26 on my production server. I’ve seen no signs that what I was testing behaves differently on a virtual, but of course that’s never certain. It let me test much more freely and without anxiety.)

I know there is no commitment on release date for V26, but with Beta 3 out, and the name V26 suggesting release this year, and no definite statements to the contrary :grinning_face:, I at least have hopes. (If there’s public information dashing my hopes, or even supporting them, I’d appreciate having it pointed out.)

While my environment is a home one, I’m hosting stuff like 75 years of family photography, 60 years of my own, and also an archive of photos (low tens of thousands) relating to science fiction fandom going back to the late 1960s. I do have multiple backups, local and off-site. So I’m rather averse to jumping on the early-adopters train for my production server.

I have ideas how to proceed on other projects without suffering too badly while staying on V25, and am looking forward to the release of V26 when I can work much more comfortably on some of my projects.

Thank you to everybody who helped me on this problem, in this topic and at least 2 others!