Quantcast
Channel: Active questions tagged mount+fstab - Ask Ubuntu
Viewing all articles
Browse latest Browse all 699

Ubuntu 18.04 - Mount Issues

$
0
0

Hoping everyone is safe and sound during the lockdown!

Linux newbie here (apologies for any incorrect terms or lack of verbose diagnostics), wondering if anyone out there can provide me a helping hand or steer me in the right direction.

Background - We have a couple of Windows Server 2012 R2 file server running DFS (n and r), with multiple DFS shares. Our Linux estate mounts these shares using SMB with multi-user mode via NTLMSSPI. The idea being, the mount config is in fstab with creds of an account that simply just does the mounting. Whilst pam_cifscreds passes the end-user credentials to the kernel keyring automatically at login. All this config is deployed and managed via puppet5.

OS = Ubuntu 18.04uname - a = 4.15.0-96-lowlatency #97-Ubuntu SMP PREEMPT Wed Apr 1 04:10:58 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Fstab:

//fileshare/Share      /net/f  cifs    vers=3.02,multiuser,_netdev,sec=ntlmsspi,file_mode=0750,dir_mode=0755,credentials=/etc/samba/credentials    0       2

Problem a) User has created a service that simply does a kinit for a service account and then runs a ls on a mounted SMB shared /net/f to test mount reliability. It runs every hour to continuously poll the mount. (Now there could just be something wrong with this test itself but bear with me). It works for a short while but fails thereafter with:

<hostname> run_test.sh[75853]: ls: cannot access '/net/f/Apps': Permission denied  

If I su as the service account running that script, and do a ls myself. /net/f, is there. Once I re-run the service after my su/ls, it resolves for a few hours. Then it fails again with the same error.

It's lead me to believe that it's the kernel keyring that's not right here?

The kern.log shows this log:

[106415.123493] audit: type=1400 audit(1588686578.583:1933): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/run/systemd/users/835005388" pid=64837 comm="krb5_child" requested_mask="r" denied_mask="r" fsuid=0 ouid=0[106415.158697] audit: type=1400 audit(1588686578.618:1934): apparmor="ALLOWED" operation="file_mmap" profile="/usr/sbin/sssd" name="/usr/lib/x86_64-linux-gnu/krb5/plugins/authdata/sssd_pac_plugin.so" pid=64837 comm="krb5_child" requested_mask="m" denied_mask="m" fsuid=835005388 ouid=0

Problem b) (Different host but running the same mount config via fstab and SMB) Related to drive mounts again. We have another service account which isn't able to ls the same /net/f as above, but can get to the other mounts whilst we su. When we try to ls on /net/f, we get:

ls: reading directory '.': Permission deniedI've tried to update the cifscreds details manually, a reboot, umount/mount. Still no luck. I think both issues are linked.

We've been using SMB 3.02 + NTLMSPPI previously but it was without the multi-user mode. The break glass solution for me is to revert the multi-user mode back to just using the mount creds as the access creds. I don't believe this is the right way to resolve it as it leaves a security hole.

My plead for help is two fold, how do others implement this? Secondly, what are we doing wrong? This was put in by our previous Linux Admin (not claiming to be one, just check my username).

Should I look into autofs and steer away from fstab? Or should I move from NTLMSPPI to Kerberos (previous admin said he couldn't find a solution for when Kerberos tickets expired as the kernel wasn't able to regenerate them, which led to shares timing out).

I appreciate any help, thanks for looking at my post :)

Update - I've enabled more verbose logging. For Problem B, seeing "Status code returned 0xc0000022 STATUS_ACCESS_DENIED" in dmesg when I try to ls in /net/f!


Viewing all articles
Browse latest Browse all 699

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>