Access to Nethserver share from printer does not work anymore

Is it possible that something changed on the recent updates concerning Fileshare Access? We have activated automatic updates with subscripted nethservers. Thats why I am asking.

Our printer, which was configured to scan documents and save them to a share on our nethserver fileserver which was working fine until yesterday. Today there are no scanned files arriving anymore. On the printer’s log we see: PC (SMB) - Scan - deleted because of error. There is no problem accessing the ressources from windows 10 pcs

We tested and the printer can still scan and save file to a share created on a windows 10 PC, but not anymore to a share provided by our neth-fileserver. Last time it worked was last thursday so I suspect that an update is the culprit here. Question @support_team - was anything changed on recent automatic updates for subscriptioned repository for ex. on smb that could cause this? The printer apparently supports ntlm v1 and v2. The only other reason that I could think of would be our neth-firewall, but then again it would also block access to the windows share, wouldn’t it? We already tried changing scanner user’s password, and even testet with a domain admin account so it cannot be a problem of access rights.

The printer has an ip reservation on our neth-firewall thus has network access to our lan and as said, it worked until last thursday while we did not change anyting in configuration.

What informations could I provide for additional debugging?

As your system used to be updated manually, let’s see the history of the samba RPM updates:

yum history pkg-info samba

By looking at the RPM changelog, there are no recent version bump.

Thanks for your quick reply. As systems are subscribed now, we configured automatic updates. Following the requested informations:

Loaded plugins: changelog, fastestmirror, nethserver_events
Transaction ID : 56
Begin time     : Fri Dec 11 06:22:15 2020
Package        : samba-4.10.4-11.el7_8.x86_64
State          : Updated
Size           : 2,229,842
Build host     :
Build time     : Tue May 12 18:31:13 2020
Packager       : CentOS BuildSystem <>
Vendor         : CentOS
License        : GPLv3+ and LGPLv3+
URL            :
Source RPM     : samba-4.10.4-11.el7_8.src.rpm
Commit Time    : Mon Feb  3 13:00:00 2020
Committer      : Andreas Schneider <>
Reason         : dep
From repo      : ce-updates
Installed by   : root <root>

Transaction ID : 56
Begin time     : Fri Dec 11 06:22:15 2020
Package        : samba-4.10.16-7.el7_9.x86_64
State          : Update
Size           : 2,262,424
Build host     :
Build time     : Wed Sep 30 19:41:42 2020
Packager       : CentOS BuildSystem <>
Vendor         : CentOS
License        : GPLv3+ and LGPLv3+
URL            :
Source RPM     : samba-4.10.16-7.el7_9.src.rpm
Commit Time    : Tue Jul 21 14:00:00 2020
Committer      : Isaac Boukris <>
Reason         : dep
From repo      : sb-updates
Installed by   : root <root>
Changed by     : root <root>

Transaction ID : 3
Begin time     : Fri May 22 23:05:02 2020
Package        : samba-4.10.4-11.el7_8.x86_64
State          : Dep-Install
Size           : 2,229,842
Build host     :
Build time     : Tue May 12 18:31:13 2020
Packager       : CentOS BuildSystem <>
Vendor         : CentOS
License        : GPLv3+ and LGPLv3+
URL            :
Source RPM     : samba-4.10.4-11.el7_8.src.rpm
Commit Time    : Mon Feb  3 13:00:00 2020
Committer      : Andreas Schneider <>
Reason         : dep
From repo      : ce-updates
Installed by   : root <root>
history pkg-info

By the way - we requested that the printer supporter would pass by as there is a newer firmware for the printer available. Maybe this will solve the issue, but if not - what could have changed with the new samba version?

Aparently the date of the update corresponds to the time, when the problem started. My boss now questions if it is a good idea to have automatic updates / subscription activated, as it was exactly this szenario, that should be avoided. :slightly_frowning_face:

Maybe I’m wrong but it seems you didn’t update since May! Switching to auto updates is a nice idea IMO :+1:

Back to the issue: what is the output of

# alternatives --list

Well, I already had activated automatic updates when we added subscription:


Anything else needed?

alternatives --list auto /usr/lib64/pkcs11/
nmap auto /usr/bin/ncat
ld auto /usr/bin/ld.bfd
cifs-idmap-plugin manual /usr/lib64/cifs-utils/
mta auto /usr/sbin/sendmail.postfix auto /usr/lib64/samba/wbclient/
mysqlbug auto /usr/lib64/mysql/mysqlbug
print auto /usr/bin/lpr.cups auto /usr/lib64/samba/wbclient/

It is the expected value :thinking:

Did you restored a configuration backup? It shouldn’t be directly related to updates but if you have a local AD provider, I’d expect you have a similar line in /var/lib/machines/nsdc/etc/samba/smb.conf

ntlm auth = yes

…otherwise NTLM auth is known to not work.

If you never enabled NTLM manually (highly discouraged) I cannot guess how did it worked.

Ensure there are no weird ACLs set on the shared folder.

If ACLs are OK, I’d suggest as workaround to enable guest access on the shared folder

Hi davide,

no there was no restore at all - just automatic update of samba from subscriptioned repo.

Following the smb.conf:

# Global parameters
        dns forwarder =
        netbios name = NSDC-PDC
        realm = AD.OURDOMAIN.COM
        server role = active directory domain controller
        workgroup = OURDOMAIN
        include = /etc/samba/smb.conf.include

        path = /var/lib/samba/sysvol/
        read only = No

        path = /var/lib/samba/sysvol
        read only = No

I actually didn’t do anything special concerning ntlm auth on the nethserver. Just had created a share, which works fine for windows clients.


On the printer which supports smb v1 and v2 we configured to save scanned files to:

\\sharename\Folder\Subfolder and that worked fine until the last samba update was installed. I checked and it does not work even with guest access enabled on the corresponding share either.

Owner of the share are domain users, and the scanner-domain-user trying to access worked fine until recently. Now it does not even work with domain admin user.

Which is the hardware involved?
Can you update the firmware?

Firmware Update has been done by a service tecnician today but the problem is persisting. Its a Konica Minolta C308. As said, the printer can save the scanned documents to a folder under a share on a windows 10 pc but not anymore folder under a nethserver file share.

That value looks bogus. It should be the NS green interface IP address – I don’t know if can be related with the issue.

Try to reproduce the issue with smbclient.

# yum install samba-client
# smbclient -d 10 -U 'OURDOMAIN\printerlogin' //NS-IP-ADDRESS/YourShare
# put somefile.txt
  • To exclude login issues: enable guest access with write permissions
  • To exclude permissions/ACLs issues: configure a new shared folder, with world-writable permissions and point to it
  • To exclude name resolution issues: use the IP address

Look, I did not change a thing manually, so no idea why dns forwarder looks like this, but that must be the standard setting. Wouldn’t it maybe make sense, to downgrade to the samba version that was installed before to see if it works again with that, as the problem clearly appeared after samba was upgraded? So it seems like a bug that is only present with the new samba version (or any other related update that happend along with it for that matter). And if so - howto do?

As a temporary workaround we have setup a windows share from a windows 10 box, so at least the users can scan and do their daily business again.

I certainly will thry as you suggested, like reproducing with samba-client, and the following suggestions.

What I already have done is: Enable guest access (I cannot set write access to guest, there is just the possibility to enable or disable guest access in file server gui section). I also tested the access by temporary configuring a domain admin account on the printer. I also tried with hostname and ip to exclude name resolution issue. So I guess permissions/ACLs issues and dns issues can be excluded.

I created a new share:

But still the same problem.

Which logs could be relevant to track this thing down? The only thing, I see is:

/var/log/samba/log.ip.of.the.printserver having entries like:

[2020/12/14 12:50:59.654752, 0] …/…/lib/param/loadparm.c:1843(lpcfg_do_service_parameter)
Ignoring unknown parameter “profile acls”

Samba logs are quite unreadable, once the debug level has been increased.

Please capture the output of smbclient -d 10 ... instead

It’s difficult for me to do further testing/debugging while the users need to be able to scan by the workaround we created. Once again, would it not be better to just revert to the samba version before last fridays update? That way we could be sure that something happened within the actual version. Or is that not easy to do / are there too many dependencies?

I will try to provide the requested info by smb-client output but that could take a while…

Your last YUM transaction seems a big leap: reverting it could be dangerous.

Also we are still not sure it is a valid issue workaround because the issue origin is still unknown.

Understood. Ok, I’ll come back with smb-client output asap. Thanks

On the printer try to login to share in this manner:

login: DOMAIN\username
password: password

with DOMAIN all in uppercase.


password: password

I had a similar problem with an app that turns a tablet into a photoframe.

After upgrading to NS 7.9 it could no longer connect to the network share where the images were saved.

By entering the credentials that way I was able to reconnect to the share.


Thanks saitobenkei. I tried both and can report success on login with username@domain.tld

It does not work with DOMAIN\username in our case.

Is this a bug that should be adressed, as it was not necessary with samba version before the last one?