File Sharing Woes, Samba, NFS, SFTP

Not gotten a response to this on Reddit or Kbin, so apologies as I cast a larger net… Standard disclosure, I’ve searched far and wide on google and duckduckgo, there’s been no coverage for this issue that my google-fu has shown me

So right off the bat, I understand that NFS is dependent on UID matching. What I can’t find is a guide to setting this up that isn’t either:

  1. Make all nfs media accessible by all, or
  2. Use advanced permissions that seem(?) reliant on professional server authentication that I can’t wrap my head around (I guess I need to take some Linux classes?) I would happily work with anyone willing to help me understand how to make this work though.

As for Samba: Well it seemed like I had everything set up well enough. I can login with each of the three users just fine. All files and folders have 02777 permissions with correct ownership. This was set after initially using just 777, and a troubleshooting answer on a Stack Exchange-like site advised 02777. However, files that I added shortly after setting up Samba and getting it running are simply not showing in client systems. And crucially, this is even the case on machines that logged in the first time after the file changes, ruling out the potential for bad client-side caching. Is there a server-side caching I’m not aware of?

I can run chmod -R 02777 * all day til the cows come home for the entire drive that’s being shared (under /mnt/4tb, yes this is related to my previous thread on reddit r/linuxadmin). But no matter how I run it alongside restarting samba (sudo systemctl restart smb), it still won’t show those newer files. Testparm succeeds, no errors in the config. FWIW, I printed the config below

[global]
	workgroup = SAMBA
	security = user
    unix extensions = no
    server string = Ravens Hoard
	passdb backend = tdbsam
    inherit permissions = yes
	printing = cups
	printcap name = cups
	load printers = yes
	cups options = raw

	# Install samba-usershares package for support
	include = /etc/samba/usershares.conf

[gen-media]
    comment = General Media Repository
    path = /mnt/4tb/general
    writeable = yes
    browseable = yes
    public = no
    create mask = 0644
    directory mask = 0755
    valid users = user4, user2, user1
    force user = user4

[intake]
    comment = Intake Directory
    path = /mnt/4tb/intake
    read only = no
    writeable = yes
    browseable = yes
    public = no
    create mask = 0644
    directory mask = 0755
    valid users = user1

[user1]
    comment = Share for user1
    path = /mnt/4tb/user1
    read only = no
    writeable = yes
    browseable = yes
    public = no
    create mask = 0664
    force create mode = 0664
    directory mask = 02755
    force directory mode = 02755
    valid users = user1

[user2]
    comment = Share for user2
    path = /mnt/4tb/user2
    read only = no
    writeable = yes
    browseable = yes
    public = no
    create mask = 0644
    directory mask = 0755
    valid users = user2

[user3]
    Comment = Share for user3
    path = /mnt/4tb/user3
    read only = no
    writeable = yes
    browseable = yes
    public = no
    create mask = 0644
    directory mask = 0755
    valid users = user1, user3
    force user = user3

Lastly in my explorations on file sharing, is SFTP/SSH-based file sharing. But with this, I don’t know of a way for Windows clients to mount the share transparently. Is this possible? Or would the Windows client be stuck with using 3rd party software like WinSCP?

FWIW, The idea of this is that the shares can be read and written to by Android through Solid Explorer, Android TV using Kodi, and Windows 10. It would have 3 users and 4 shares, as can be seen in the samba config. Any help towards getting one of these methods working for this purpose would be very much appreciated.

The Unix mode bits aren’t the only permissions that determine what can be accessed. There are also ACLs and SELinux permissions (and firewalls and share-level permissions). It is frustratingly complex. But you will need to verify that all the permissions in all those systems are correct.

1 Like

Appreciate the response. I did follow the Fedora Guide for Samba which included setting an SELinux flag for the folder (sudo semanage fcontext --add --type "samba_share_t" "folder path"). How do I verify that this set things correctly, and what do I do with the ACLs you referenced?

Use ls -Z <file> or ls -Zd <directory to view SELinux permissions.

Did "folder path" end with something like (/.*)?? That pattern at the end ensures that the permissions apply to all the subdirectories.

1 Like

Interesting. That seems like it could be the issue. So it did include the (/.)?, and every file that was present at the time of setup got it. Of course by that emphasis, I imagine you can guess what the state is for the new files… unconfined_u:object_r:unlabeled_t:s0.

How do I ensure this attribute gets applied to files that are copied into the share?

When you long-list files that have ACLs set a + will appear at the end of the first column. For example:

# ls -al gbartho
total 43
dr-xr-x---+   4 root root   11 Aug 17 12:44 .
dr-xr-xr-x. 108 root root  108 Feb  4  2023 ..
-rw-rw----+   1 root root  951 Aug 17 12:45 .bash_history
-rw-rw----+   1 root root   18 Aug 17  2022 .bash_logout
-rw-rw----+   1 root root  261 Aug 17  2022 .bash_profile
-rw-rw----+   1 root root  376 Aug 17  2022 .bashrc
drwx------+   3 root root    3 Aug 25  2022 .config
-rw-rw----+   1 root root    0 Aug 17  2022 .hushlogin
-rw-------+   1 root root   20 Aug 22  2022 .lesshst
drwx------+   2 root root    3 Aug 22  2022 .ssh
-rw-rw----+   1 root root 9340 Aug 16 15:05 .viminfo

If there are ACLs, use getfacl <path> to see what they are.

# getfacl gbartho/
# file: gbartho/
# owner: root
# group: root
user::r-x
user:gbartho:rwx		#effective:r-x
group::---
mask::r-x
other::---
default:user::rwx
default:user:gbartho:rwx
default:group::---
default:mask::rwx
default:other::---
1 Like

SELinux isn’t really designed for MS Windows environments. The problem you are encountering is because you are trying to get two vastly different systems that were developed independently to inter-operate. That is what Samba is designed to do. But I’m not entirely familiar with how it handles SELinux permissions. There is, however, a way you can force the SELinux permissions to always be a given value – you can set them for the entire file system mount using the context=... setting. How are you mounting the “4tb” filesystem?

Yeah, once again a large benefit to FLOSS is also a large downside, puzzle pieces aren’t quite always fitting together…

So I have the drive in an fstab entry. Is that context= line an item I can add to the end of the mount entry in fstab? And will it complain about lost+found like it did when I tried the very first time?

Yes. You need to be a little careful with editing the lines in /etc/fstab because an improper line can cause your system to fail to boot (but you should be able to undo the error from a rescue environment).

Your fstab line might look something like the following.

LABEL=MYFILES /mnt/4tb ext4 defaults,context=system_u:object_r:samba_share_t:s0,nofail 0 0

Again, I haven’t tested this, but I think that might work.

I’m not sure. I don’t remember encountering a lost+found setting or value in /etc/fstab. That is normally just a (somewhat superfluous) directory that ext filesystems put at their root (you can just delete it).

It doesn’t at all on the Windows side - Windows doesn’t care at all about SELinux context as long as the file can be served on its side. There’s something similar, but nuanced with NFS shares - it will just show the default context on the mount side, which you can override on the client side, for example to use the mount for a web server: mount server:/export /local/mount/point -o \ context="system_u:object_r:httpd_sys_content_t:s0"

With SMB/cifs, the bigger frustration is that Windows ACLs and Unix perms generally don’t line up, si if a file’s permissions are able to be modified on the Windows side, it can create entirely non-sensical modes on the Linux side.

1 Like

I strongly recommend setting nofail,_netdev for fstab options with NFS and cifs.

3 Likes

I would bet that this is an external and removable drive and the new files he added were added while it was connected to a different system (one that does not have or even support that SELinux rule). The best option is probably to set the permissions on the mount. Otherwise, he would have to run restorecon -rv /mnt/4tb every time he adds files to the external drive from a non-SELinux system.

1 Like

Close. The 4tb drive is an internal SSD, but the new files were copied from external (Ironically an external that first got the contents from another Fedora 38 system, but that’s irrelevant since it isn’t aware of the flag needed here)

That all aside, Thanks @glb and everyone else in here!! Adding ,context=system_u:object_r:samba_share_t:s0,nofail to the end of the options in fstab worked (and didn’t brick my boot! :tada: ), and even before logon all the shared files that previously lacked the SELinux flag now have it and are showing up to Samba clients!

Thanks again everyone!