Permissions behave weirdly when mounting SMB share from TrueNAS on Linux box (or virtual)

TrueNAS General
,
1

This has gotta be a well-known issue with a simple fix, but searching here or broadly isn’t finding me anything.

Running TrueNAS Scale 25.10.6, home server setup.

The general advice seems to be to use SMB for sharing things in the home environment, since we don’t usually (and in fact I don’t) have Kerberos or any central identity control system running. So I’m trying to do that.

I did this back on TrueNAS core with good results. I had a gap in doing much at home, and am now trying to get the working environments for things I was working on back up.

The basic problem is that things mounted via SMB share on Linux don’t have working permissions. Everything has execute permission, and chmod commands complete successfully but do not change the permissions as shown by ls. A certain amount of random weirdness can be ignored…except that this shows up as updates on every single tracked file in my git repositories. That’s NOT bearable, of course.

I tried creating a new dataset for testing things, and shared it, and I’m getting the same results, so it doesn’t seem to be any obscure buried option that got set in the past (it’d have to be something that looked sane and right so I set it now).

ddb@fsfsdev3:~/shr2
$ echo This is a text file! > test.txt
ddb@fsfsdev3:~/shr2
$ ls -al
total 4.7k
drwxr-xr-x 2 ddb ddb 0 Aug 13 16:11 .
drwxr-x— 12 ddb ddb 4.1k Aug 13 16:11 ..
-rwxr-xr-x 1 ddb ddb 21 Aug 13 16:11 test.txt
drwxr-xr-x 2 ddb ddb 0 Aug 13 15:56 .zfs
ddb@fsfsdev3:~/shr2
$ chmod 600 test.txt
ddb@fsfsdev3:~/shr2
$ ls -al
total 4.7k
drwxr-xr-x 2 ddb ddb 0 Aug 13 16:11 .
drwxr-x— 12 ddb ddb 4.1k Aug 13 16:11 ..
-rwxr-xr-x 1 ddb ddb 21 Aug 13 16:11 test.txt
drwxr-xr-x 2 ddb ddb 0 Aug 13 15:56 .zfs

What dataset and share options should I be suspicious of? Is there a clean way to capture all the dataset and share settings from the command line or in the gui? I kind of expect you’ll want more information, and it looks like some things that can only be set on creation don’t show in the GUI later?

The mount command was

sudo mount -t cifs -o username=ddb,uid=ddb,gid=ddb //fsfs.local/ddbshare2 /home/ddb/shr2

(It prompts me for the password, that’s fine for this use.)

2

Mount with noperm. That prevents cifsacl from trying to be creative about layering POSIX permissions on SMB mounts. This is usually the primary cause of weird linux permissions behavior. Kernel guessing rather than trying to do the op and getting a server response.

3

No change:

$ sudo mount -t cifs -o username=ddb,uid=ddb,gid=ddb,noperm //fsfs.local/ddbshare2 /home/ddb/shr2
Password for ddb@//fsfs.local/ddbshare2:
ddb@fsfsdev3:~
$ cd shr2
/home/ddb/shr2
ddb@fsfsdev3:~/shr2
$ echo new test file > test.txt
ddb@fsfsdev3:~/shr2
$ ls -al
total 4.7k
drwxr-xr-x  2 ddb ddb    0 Aug 13 16:26 .
drwxr-x--- 12 ddb ddb 4.1k Aug 13 16:11 ..
-rwxr-xr-x  1 ddb ddb   14 Aug 13 16:26 test.txt
drwxr-xr-x  2 ddb ddb    0 Aug 13 15:56 .zfs
ddb@fsfsdev3:~/shr2
$ chmod 600 test.txt
ddb@fsfsdev3:~/shr2
$ ls -al
total 4.7k
drwxr-xr-x  2 ddb ddb    0 Aug 13 16:26 .
drwxr-x--- 12 ddb ddb 4.1k Aug 13 16:11 ..
-rwxr-xr-x  1 ddb ddb   14 Aug 13 16:26 test.txt
drwxr-xr-x  2 ddb ddb    0 Aug 13 15:56 .zfs
ddb@fsfsdev3:~/shr2
4

What profile did you use to create the share?

5

Is that what the GUI calls “purpose”? ddbshare2 was created as a “multi-protocol share”.

6

Yeah, try creating shares with different profiles, as this will change the permissions model. You may even need to use the legacy share profile, and then manually adjust the auxsmbconf parameter to get the permissions masking you want.

7

Not sure we’re talking about the same thing, “legacy” isn’t one of the choices for that?

image
image698×740 19.1 KB

8

Legacy is hidden and only reveals itself once created. You have to use the API (i.e., midclt call sharing.smb.create '{ "purpose": "LEGACY_SHARE", "name": "your_share_name_here", "path": "your_share_path_here", "enabled": true, "options": { "auxsmbconf": "raw smb.conf directives here, delimited with \n" } }') to create it.

2 Likes
9

Okay, got the share converted over.

Will now be tweaking random things for a while! Must remember to save the actual multipurpose-share version so I can be sure I know what I changed!

Should I be looking for smb options to try in auxsmbconf?

Is it really this hard to create shares that are compatible with git? I mean, it breaks other things, or at least looks weird, too, but that one is a complete deal-breaker, I can’t commit anything from a repo I’m accessing this way, it will mess things up.

ddb@fsfs:~$ midclt call sharing.smb.query '[["id","=",16]]' | jq '.[0] | {id,name,purpose,options}'
{
  "id": 16,
  "name": "ddbshare2",
  "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": "daffe5b0-4b74-4345-97d0-7a60720d6a43",
    "auxsmbconf": ""
  }
}
10

You’ll need to experiment with various masks. See the smb.conf reference. In particular, you’ll probably need to set some combination of the following:

  • create mask = 0644
  • directory mask = 0755
  • force create mode = 0644
  • force directory mode = 0755
1 Like
11

Thanks, helps a LOT to know roughly where to start!

12

Yes, I had to use the legacy share to move from Core to CE, and preserve an existing old-style Samba [homes] share, and also another share with forced user/group and forced create/directory modes. Once I made it past the migration, I ended up recreating the home directories with Private Datasets Share and moving the forced user/mode share to NFS, where I could set the mapall user/group.

13

Maybe I don’t understand the “force create x” parameters; but in any case, they aren’t set according to testparm -x on my server, either globally or specifically for shr2, the new test share. They don’t say to force the execute bit on, but the execute bit is on; therefore they’re not the problem?

In any case, part of the problem is that chmod doesn’t work (no error, but no change to permissions). Which means the force create mode is an unlikely root cause.

14

Possibly I have found the problem. I looked at what mount reports for the mount (the mount is exactly as I pasted above, that’s in a script that I use).

//fsfs.local/ddbshare2 on /home/ddb/shr2 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,noperm,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1)

Note the file_mode and dir_mode settings (and the nounix setting). With those happening to correspond exactly to the bogus permissions I can’t change, that seems very hopeful!

Dunno why they got set; default, or forced from the server end? I’ll read their docs, and if that seems encouraging, try overriding in the mount command on the client.

15

I’m closing in on the hypothesis that the problem is the server is defaulting to refusing unix integration.

It looks like Samba 3 and later support it in a secure form. It looks like TrueNAS CE 25.10.6 is running smbd 4.22 (from the log files).

But the man page for smb.conf shows nothing for no unix (and many irrelevant hits, not in parameter names, for unix). And testparm doesn’t show any unix or no unix parameter.

Again, smells like I’m looking under the wrong rocks maybe? Help?

16

Nope. Looks like SMB3 Unix Extensions is turned off by default, but turning it on for the share (and restarting smbd, and unmounting and remounting the share) didn’t help.

And setting the create mask to 644 does not change how new files are created, either; they still come out 755.

Something is just completely bonkers, and the documentation doesn’t even hit at right directions. Anybody?