Best way to setup a share for both Windows and Linux access

[nicholas-h]

Accessing my new SMB shares on TrueNAS Scale from Windows via Map Network Drive: works perfectly, and so easy to configure.

But on Linux... ehhh not so easy. To cut to the chase, should I setup SEPARATE "NFS" style shares for Linux users--pointing to the same Dataset?

Here's are the issues I'm having with SMB shares on Linux Mint (v21.1, Cinnamon 5.6.7):

1. [OK] No problem seeing my share data through Mint's file explorer "Network" tab. I can browse file, open them, etc. I can save-as and navigate and save to any folder on my SMB share.

2. [FAIL] Windows apps in Wine absolutely cannot see my SMB shares/files. There is just no way to navigate to them.

3. [PARTIAL-FAIL] Some older Linux apps also cannot navigate to any SMB share. For example, notepadqq's file explorer shows only local folders and "Computer" but no option to reach Network shares. However, I can drill deep into /run/user/1000/gvfs/smb-share:server=truenasl.local,share=myshare which is completely unintuitive not to mention a ridiculously long path.

4. [DIFFICULT] I can attempt to mount vis cifs-utils this to a local /mnt/myshare folder, setup a local credentials file with clear-text password inside it (seems like bad practice) and edit my /etc/fstab file with some "complex" configuration settings to map this share, and I can hope that it deals with auto connect/disconnect issues... but that seems overly complex and possibly flakey.

5. [NON-EXISTENT] I could dream of a feature to do as Windows does.. to simply "Map Network Drive" via a GUI and mount that to my path of choice and be done with it. How nobody has thought of this by 2023... beyond me but more likely, there is no need for this because I'm thinking about this all wrong in Linux (?).

6. [DON'T USE SMB FOR LINUX???] Yeah, maybe I'm doing this all wrong. Maybe I should be using SMB shares for Windows users and NFS shares for Linux users (both pointing to the same Dataset in TrueNAS Scale? Maybe that's easier to mount than a CIFS share?

Your thoughts?

Thank You,
Nicholas

 

[winnielinnie]

Don't use GVFS to access your SMB shares.

Use the native kernel module (cifs) method instead.

4. [DIFFICULT] I can attempt to mount vis cifs-utils this to a local /mnt/myshare folder, setup a local credentials file with clear-text password inside it (seems like bad practice) and edit my /etc/fstab file with some "complex" configuration settings to map this share, and I can hope that it deals with auto connect/disconnect issues... but that seems overly complex and possibly flakey.

This means you either need to:

• manually mount/unmount them each time with the mount command in the terminal, or...
• specify entries in your fstab, or...
• use systemd-mounts and automounts
• use Smb4K (KDE only)

While GVFS (used by the file manager) is convenient and easy, it lacks in features, can cause issues, and under-performs compared to the kernel module method.

I personally use the systemd method. You can create your own separate .mount/.automount files, or just use the proper flags in your fstab if you wish to contain everything to a single file.

5. [NON-EXISTENT] I could dream of a feature to do as Windows does.. to simply "Map Network Drive" via a GUI and mount that to my path of choice and be done with it. How nobody has thought of this by 2023... beyond me but more likely, there is no need for this because I'm thinking about this all wrong in Linux (?).

After configuring the above (yes, I'll admit it's not "user friendly"), you can accomplish the same results by using panel shortcuts and bookmarks. One-click, seamless access.



EDIT:

setup a local credentials file with clear-text password inside it (seems like bad practice)

You can protect this file as read-only for only your specific user account. After all, if someone has unhindered access to your computer, under your account, what's stopping them from just copying/stealing your SSH keys? It's at this point you have more serious problems than "Someone might see my SMB password."

 

[Patrick M. Hausen]

To add to that NFS has got a permission model that is completely different from SMB. Mounts are system to system with the client's user IDs implicitly trusted by the server. I would not try to mix the two if I can avoid it.

 

[MisterE2002]

things can get difficult really fast. In my case i use SMB. My laptop is using ID 1001 and my jails also use this ID. So no ACL's required. I only changed the ownership in the SCALE GUI to the user with ID 1001.
This way i can create data, but also the jails.

You can also look at "noperm" as mount parameter for cifs.

 

[WI_Hedgehog]

I use SMB because Windows clients need access. I don't use anything else because Linux machines can use SMB and the more complexity there is the more potential there is for unexpected collisions and unhandled exceptions which can lead to failure, or worse: silent data corruption.

KISS: Keep It Super-Simple

 

[nicholas-h]

To add to that NFS has got a permission model that is completely different from SMB. Mounts are system to system with the client's user IDs implicitly trusted by the server. I would not try to mix the two if I can avoid it.

Thanks for your help above. I got this mounting through, but it's very quirky:

In /etc/fstab, I have the following (which works when I mount /mymount)

//192.168.1.10/myshare /mymount cifs credentials=/home/myname/.mycreds,dir_mode=0770,file_mode=0770,uid=1000,gid=1000

However, there are a few problems:

1. When I open, edit, and save a file (e.g., using Mint's default text editor) it saves the file with no complaint, but when I try to exit the text editor, it still thinks the file was not saved (but it WAS saved because if I cat the same file on the command line, my changes are indeed there). This repeats in a loop as I cannot close the document. If I press Cancel instead, I see a message that says, "The file was changed on disk, do you want to reload the file?". If I click Yes, it apparently reloads the file, but I still cannot exit the program for the same reason. I MUST CLOSE WITHOUT SAVING each time after after CTRL+S saving. Maybe this is some sort of sync issue with how the editor determines if a file was changed and how SMB captures changes. I was thinking a timestamp mismatch between the TrueNAS server and my linux machine but they appear to be the same.

2. When I reboot my computer, the mounts cannot be established automatically. I suppose some delay is needed. I must manually call sudo mount /mymount (which reads the /etc/fstab settings).

Both of these issues are very quirky. The same shares work perfectly from my Windows 11 client. My goal here is to get off Windows, but so far, Windows is 10x better at this stuff...

 

[winnielinnie]

2. When I reboot my computer, the mounts cannot be established automatically. I suppose some delay is needed. I must manually call sudo mount /mymount (which reads the /etc/fstab settings).

This is what systemd mount/automount units are for.

If you want to stick to the fstab, then you can still specify certain entries to use systemd's automount method.

For example, this is a sane default to use for SMB shares on a local network NAS server. You can insert these parameters anywhere in the "options" field of the mount entry in your fstab.

Code:

noauto,x-systemd.automount,x-systemd.mount-timeout=30,_netdev

 

[nicholas-h]

This is what systemd mount/automount units are for.

If you want to stick to the fstab, then you can still specify certain entries to use systemd's automount method.

For example, this is a sane default to use for SMB shares on a local network NAS server. You can insert these parameters anywhere in the "options" field of the mount entry in your fstab.

Code:

noauto,x-systemd.automount,x-systemd.mount-timeout=30,_netdev

This has solved my mounting issues, thank you :)

However, there is still a file sync issue with TrueNAS SMB shares and Linux cifs. After saving in any Linux application, the file appears to change again externally, causing the Linux app to ask the user if they want the file to be reloaded. Also, it prevents exiting without cancelling changes in some random cases. See this link on stackexchange which is still valid today:

Suppress/bypass “file has changed” errors when editing cifs/Samba files

[I originally posted about this on the vi/vim stackexchange, but it's increasingly clear that the core issue is more the filesystem than the editor that's complaining about it] TL;DR -- Files on a...

unix.stackexchange.com

The workarounds discussed appear to be hacks and may increase network overhead. How can this be? Half the world uses Linux/Mac, half the world uses Windows, and SMB shares are quite common to share files between them--but they don't play well together? Clearly that can be the case right? ...Or this would be a stop-ship issue for most companies I would assume.

Anyway, would I be better off setting up an NFS share and installing the NFS client on Windows?

 

[Johnny Fartpants]

SMB is the way for multi OS environments. Don’t try and shoehorn NFS into Windows.

 

[winnielinnie]

How can this be? Half the world uses Linux/Mac, half the world uses Windows, and SMB shares are quite common to share files between them--but they don't play well together? Clearly that can be the case right? ...Or this would be a stop-ship issue for most companies I would assume.

I've never had this issue, which is peculiar.

Can you post the outputs of the following two commands?

Code:

mount | grep 192.168.1.10

And the second output being the exact entry (full line) in your fstab?

You can filter out anything that might be private information with a bunch of XXXXXXXX.

 

[nicholas-h]

I've never had this issue, which is peculiar.

Can you post the outputs of the following two commands?

Code:

mount | grep 192.168.1.10

And the second output being the exact entry (full line) in your fstab?

You can filter out anything that might be private information with a bunch of XXXXXXXX.

It's actually on x.x.1.2...

/etc/fstab:

//192.168.1.2/hypersmb /hypersmb cifs credentials=/home/myusername/.mycreds,dir_mode=0770,file_mode=0770,uid=1000,gid=1000,noauto,x-systemd.automount,_netdev

mount results:

//192.168.1.2/hypersmb on /hypersmb type cifs (rw,relatime,vers=3.1.1,cache=strict,username=mysmbusername,uid=1000,noforceuid,gid=1000,noforcegid,addr=192.168.1.2,file_mode=0770,dir_mode=0770,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,x-systemd.automount,_netdev)

btw.. I was able to replicate this issue in a completely different linux distro (zorin)

 

[winnielinnie]

Notable differences compared to mine:
cache=loose,actimeo=60,closetimeo=5

The ones highlighted in bold I intentionally specified in my mount options. While "closetimeo" is a default parameter (which I don't believe is available to you on Linux Mint 21.1, since you're still on the 5.15 kernel.)

See if specifying cache=loose and actimeo=60 alleviate this issue. If you're the only one accessing that share, then you'll only benefit from the more breathable actimeo value and of course a "loose" cache policy, which will lessen the amount of repetitive transfers over the network.

EDIT: Also, not sure if it makes a difference in your case, but I don't specify "execute" permissions for my files (i.e, "file_mode"). I use "6" instead of "7". Only my "dir_mode" allows the "execute" bit (which is really "traverse" for directories).

 

[nicholas-h]

EDIT: Also, not sure if it makes a difference in your case, but I don't specify "execute" permissions for my files (i.e, "file_mode"). I use "6" instead of "7". Only my "dir_mode" allows the "execute" bit (which is really "traverse" for directories).

As a developer, I need to execute scripts and programs (to test them) that live on my SMB shares. Otherwise, I'd completely agree. When I set the above to 660, I could not even echo hello world from a bash script, even with sudo.

See if specifying cache=loose and actimeo=60 alleviate this issue. If you're the only one accessing that share, then you'll only benefit from the more breathable actimeo value and of course a "loose" cache policy, which will lessen the amount of repetitive transfers over the network.

• cache=loose did not help.
• actimeo=60 also did not help, nor did 1, 10, or 100 (although I saw some variability) and sometimes the error would appear IMMEDIATELY after re-opening a file that I recently closed. When this error occurs, it happens very quickly--virtually immediately after saving or immediately when opening the file. The way to test this is to open the file, make a change, save it, close it, then open it, and repeat. After a few cycles, you may see the error, if not immediately.
• actimeo=0 THIS WORKED as noted the stackexchange link in my prior post. I do not see any additional unexpected network traffic. I see traffic only when saving the file and opening it, which is expected without caching. I'm OK with that. I have a 2.5G connection to my sever (soon 10G) and my files are on four insanely fast M.2 SN850X drives in a bifurcated (4x4x4x4) 16X slot, setup as a RAID1z with a backup HD MIRROR on NAS-spec drives, and that is even backed up offisite nightly.

Anyway, IMHO, this is still a bug--likely in the Ubuntu kernel, not in TrueNAS SCALE. Caching should not cause the application to think the file has changed. If anything, it should prevent it from seeing any changes. Bottom line is that the default behavior when attaching an SMB share should not be like this.

BTW, I'm contemplating on setting up NextCloud to sync files to my local drive (like OneDrive) and then I don't have to worry about any of this stuff. I'll have the maximum performance advantage when working with my files, ability to work offline, and effectively an additional backup of my work. I just hope it's as smart as OneDrive sync, which has not failed me in years.

Thank you for all for all your help !!!

-Nicholas