Scan to folder appears to be forgetting credentials

[badgerfruit]

Hello all.

We have a Ricoh MPC5503 printer scanner thing and have recently setup a new server running CentOS Linux release 7.6.1810 (Core) for it to scan to. The server uses AD auth to verify access and all this works (I can ssh to the machine using my AD creds and I can access the SMB shares using the AD creds).

The problem is, the scanner seems to happily create files where I tell it to but instead of them being created and owned by scanner@mydomain.com:scanner@mydomain.com, they're being created by nobody:nobody.

I have searched the /var/log/samba/log.smb, /var/log/messages and every other log file I can think of, but there's nothing mentioning the scanner popping in to say hello, here's a file ... and so on. I have checked the AD user that we've programmed the scanner to authenticate with and it logs on to Putty just fine and when I touch a new file, it creates it with scanner@mydomain.com:scanner@mydomain.com as expected.

Anyone any ideas on any log files I can tail, or why it could be doing what it's doing?!

smb.conf:

Code: Select all

[global]

# ----------------------- Network-Related Options -------------------------
        workgroup = MYDOMAIN
        server string = Samba Server Version %v
        netbios name = myserver
        
# --------------------------- Logging Options -----------------------------
        log file = /var/log/samba/log.%m
        max log size = 50

# ----------------------- Standalone Server Options ------------------------
        security = user
        passdb backend = tdbsam

# ----------------------- Domain Members Options ------------------------
        security = ads
        encrypt passwords = yes
        passdb backend = tdbsam
        realm = mydomain.com

# ----------------------- Shares ------------------------
[documents]
        comment = Documents
        path = /path/to/folder
        browseable = yes
        guest ok = yes
        writable = yes
        locking = no
        public = yes
        force create mode = 0777
        force directory mode = 0777

realm list:

Code: Select all

[root@silver log]# realm list
mydomain.com
  type: kerberos
  realm-name: MYDOMAIN.COM
  domain-name: mydomain.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
  login-formats: %U@mydomain.com
  login-policy: allow-realm-logins

Scanner user is member of mydomain.com/My System Users/ OU
sssd is active, there's nothing in the sssd.conf which would restrict to specific OU:

Code: Select all

[sssd]
domains = mydomain.com
config_file_version = 2
services = nss, pam

[domain/mydomain.com]
ad_domain = mydomain.com
krb5_realm = MYDOMAIN.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad

[hunter86_bg]

What happens when you disable the gues user?
Is it still possible to create files, or nothing is created ?
What are the permissions of your shared folder?
Is it 2777 or something else?

[badgerfruit]

What happens when you disable the gues user?
Is it still possible to create files, or nothing is created ?
What are the permissions of your shared folder?
Is it 2777 or something else?

Thank you for the reply;
The parent folder is 777 owned by root:"domain users@mydomain.com".
When I set "guest=no" in my smb.conf ......... it still creates the file as nobody:nobody

[hunter86_bg]

For now you can setguid (2777) which will make all new files/dirs to be owned by the group of the share.
Of course , you should do this only if all users are part of that group.

You can run 'testparm' to see the current config.Maybe an old option is still forcing it.

[hunter86_bg]

Try to add in the global config:

Code: Select all

map to guest = never

This should prevent mapping the scanner to guest, but it could prevent any actions from it - so just test for a few minutes and remove it.
Can you login as that user on the samba and run:

Code: Select all

kinit

After that run:

Code: Select all

klist

If it reports tickets, then the user is 'resolvable' and should be OK.