How do I enable SMB3 UNIX Extensions?

The unix extensions are enabled by default in samba 4.23.x , Scale is still on samba 4.21.x . I’d like to enable them now to fix an issue I’m having. But I can’t see a place for global parameters in the GUI. Can they be enabled in the individual shares, or do I need to mess with smb4.conf ?

What issue are you trying to fix? They are not available because they are experimental in the version we have.

symlinks not setting permissions correctly (by which I mean not as expected, I’m getting permission errors) with mfsymlinks enabled. It is possible it won’t fix the issue, but I’d like to try it.

I’m doing a silly thing out of curiosity and trying to get Steam Proton running on an SMB mount as my NAS is faster than local.

How are you mounting? What is the exact operation that’s failing?

in fstab

//smbmulti.local/games /mnt/games cifs multichannel,credentials=/root/.moviescreds,noperm 0 0

gives error

OSError: [Errno 95] Operation not supported: ‘../AppData/Local’ → ‘/mnt/games/SteamLibrary/steamapps/compatdata/1145360/pfx/drive_c/users/steamuser/Local Settings/Application Data’

//smbmulti.local/games /mnt/games cifs mfsymlinks,credentials=/root/.moviescreds,noperm 0 0

gives error

Nov 15 16:39:56 fedora steam[6381]: wine: ‘/mnt/games/SteamLibrary/steamapps/compatdata/1145360/pfx’ is not owned by you

Leaving multichannel in gives a inode error only when mfsymlinks is included

Permissions on share vs local after steam creates each of them (using the last fstab config above).

ls -l /mnt/games/SteamLibrary/steamapps/compatdata/1145360/pfx
total 1729
-rwxr-xr-x 1 root root 0 Nov 14 22:55 creation_sync_guard
drwxr-xr-x 2 root root 0 Nov 14 22:55 dosdevices
drwxr-xr-x 2 root root 0 Nov 14 22:55 drive_c
-rwxr-xr-x 1 root root 3727886 Nov 14 22:55 system.reg
-rwxr-xr-x 1 root root 3727887 Nov 14 22:18 system.reg.old
-rwxr-xr-x 1 root root 4190 Nov 14 22:18 userdef.reg
-rwxr-xr-x 1 root root 27718 Nov 14 22:18 user.reg

ls -l /home/me/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/compatdata/1145360/pfx
total 7424
-rw-r–r–. 1 me me 0 Nov 15 16:49 creation_sync_guard
drwxr-xr-x. 1 me me 348 Nov 15 16:49 dosdevices
drwxr-xr-x. 1 me me 138 Nov 15 16:49 drive_c
-rw-r–r–. 1 me me 3807102 Nov 15 16:49 system.reg
-rw-r–r–. 1 me me 3727887 Nov 15 16:49 system.reg.old
-rw-r–r–. 1 me me 4190 Nov 15 16:49 userdef.reg
-rw-r–r–. 1 me me 53139 Nov 15 16:49 user.reg

serverside default user is floz, default group is user. Client is logged in locally as ‘me’, to samba server as ‘floz’.

Expected behavior is ‘me’ owns the data, actual behavior is ‘root’ owns the data only on the share.

Note this only affects steam software launching via Proton, which uses symlinks, it does not affect linux native software launching via Steam.

sudo chown -R me:me /mnt/games/SteamLibrary/steamapps/compatdata/1145360/pfx

doesn’t correct the permissions, owner remains root.

Edit:Apparently this is normal behaviour, it does nothing and fails silently ( [SOLVED] mount.cifs mounts share with owner=root, can not chmod - Raspberry Pi Forums ) the ‘fix’ is to mount as the desired user by adding ,uid=%userID,gid=%groupID to the fstab entry. Will try and update.

Update: works with

//smbmulti.local/games /mnt/games cifs mfsymlinks,uid=1000,gid=1000,credentials=/root/.moviescreds,noperm 0 0

where the gid and uid were the IDs associated with the logged in account, found with the ‘getent passwd‘ command.

I don’t like that it required adding 3 parameters (mfsymlinks,uid=1000,gid=1000) to fstab. Supporting symlinks and defaulting to the current user, rather than root, seem reasonable expectations. So I’m still curious to know if the SMB UNIX extensions will fix it, as the samba documents suggest improved symlink handling with the extensions.

And with mfsymlink and multichannel enabled I get:

CIFS: VFS: Autodisabling the use of server inode numbers on \smbmulti.local\games
CIFS: VFS: The server doesn’t seem to support them properly or the files might be on different servers (DFS)
CIFS: VFS: Hardlinks will not be recognized on this mount. Consider mounting with the “noserverino” option to silence this message.

But no apparent issues caused by that yet.