*Resolved* Blew up my access

I have been struggling with shares for nearly a year. My old configuration of Windows 10 PC and TrueNAS core 13.3 had no issues, but the PC’s hardware was tired. I built a new PC with windows 11 and my SMB share would fail every time. I kept getting Windows Security promting for a pin with no data entry box or “Ok” button, only “Cancel.”

Mind you, the whole time my NFS file share on my linux computers worked fine.

Today I decided to tackle the issue once and for all, I upgraded the NAS to TrueNAS scale. I updated my debian computer, and set to sorting out the Windows issue.

I tried clearing credentials, then using windows powershell to map the drive. That didn’t work.

I tried using command prompt to store the credentials for my standard alpha numeric user name (not root).

I checked all my shares, I verified groups/users have access, I’ve been at it for nearly 12 hours now and am at a complete loss. Whats worse is now my debian machine no longer has access to the folders inside the share, i can open them but they are red X’d and say I do not have permission to access them.

I honestly believe I started out with a Windows issue and have now turned it into a Windows issue, and a permissions/shares issue on the server side.

Please help. Let me know what information you need to help diagnose the issue and I will provide it.

In an old similar thread (didnt fix my issue) someone asked for the testparm -s so I thought I would add it here just in case: Linux freenas 6.12.105-production+truenas #1 SMP PREEMPT_DYNAMIC Mon Aug 31 21:20:44 UTC 2026 x86_64

    TrueNAS (c) 2009-2026, iXsystems, Inc. dba TrueNAS
    All rights reserved.
    TrueNAS code is released under the LGPLv3 and GPLv3 licenses with some
    source files copyrighted by (c) iXsystems, Inc. All other components
    are released under their own respective licenses.

    For more information, documentation, help or support, go here:
    http://truenas.com

Warning: the supported mechanisms for making configuration changes
are the TrueNAS WebUI, CLI, and API exclusively. ALL OTHERS ARE
NOT SUPPORTED AND WILL RESULT IN UNDEFINED BEHAVIOR AND MAY
RESULT IN SYSTEM FAILURE.

Welcome to FreeNAS
root@freenas[~]# testparm -s
Load smb config files from /etc/smb4.conf
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

Server role: ROLE_STANDALONE

Global parameters

[global]
bind interfaces only = Yes
disable spoolss = Yes
dns proxy = No
interfaces = 127.0.0.1
load printers = No
logging = file
max log size = 5120
passdb backend = tdbsam:/var/run/samba-cache/private/passdb.tdb
printcap name = /dev/null
registry shares = Yes
restrict anonymous = 2
server multi channel support = No
server string = FreeNAS Server
smb3 directory leases = No
winbind request timeout = 2
zfs_core:zfs_block_cloning = False
zfs_core:zfs_integrity_streams = False
idmap config * : read only = True
idmap config * : range = 90000001 - 90010001
rpc_server:mdssvc = disabled
rpc_daemon:mdssd = disabled
fruit:zero_file_id = False
fruit:nfs_aces = False
idmap config * : backend = tdb
create mask = 0664
directory mask = 0775

[kentexian]
ea support = No
path = /mnt/DefaultVol/kentexian
posix locking = No
read only = No
smbd max xattr size = 2097152
vfs objects = streams_xattr shadow_copy_zfs ixnas zfs_core io_uring
fruit:resource = stream
fruit:metadata = stream

yo look at the testparm dump

interfaces = 127.0.0.1
bind interfaces only = Yes

that means smbd is only listening on localhost, so windows/linux clients on the lan never really reach it clean. check Network → Interfaces / SMB bind settings and make sure its bound to your real nic (or leave it unbound), not just 127.0.0.1

after that for the debian red-X folders id reset the dataset ACL in the UI (owner + group that matches your share user, apply recursively) then remount. win11 pin popup is a separate windows credential manager thing once smb is actually reachable

start with the bind address first, that one alone explains a lot

Thanks for the reply.

-I cleared the bound IP and the web interface IP is set to 0.0.0.0.

-Reset the ACL for owning user and applied recursively but that did not fix the Linux NFS share’s red-X folders.

At this point I don’t even know what user the NFS share tries to connect as, it never asks me for server credentials. I just use sudo mount and password. Any idea how to ID which user it is?

new testparm dump:
Global parameters

[global]
bind interfaces only = Yes
disable spoolss = Yes
dns proxy = No
load printers = No
logging = file
max log size = 5120
passdb backend = tdbsam:/var/run/samba-cache/private/passdb.tdb
printcap name = /dev/null
registry shares = Yes
restrict anonymous = 2
server multi channel support = No
server string = FreeNAS Server
smb3 directory leases = No
winbind request timeout = 2
zfs_core:zfs_block_cloning = False
zfs_core:zfs_integrity_streams = False
idmap config * : read only = True
idmap config * : range = 90000001 - 90010001
rpc_server:mdssvc = disabled
rpc_daemon:mdssd = disabled
fruit:zero_file_id = False
fruit:nfs_aces = False
idmap config * : backend = tdb
create mask = 0664
directory mask = 0775

[kentexian]
ea support = No
path = /mnt/DefaultVol/kentexian
posix locking = No
read only = No
smbd max xattr size = 2097152
vfs objects = streams_xattr shadow_copy_zfs ixnas zfs_core io_uring
fruit:resource = stream
fruit:metadata = stream

OK, figured out the issue on the NFS red-x folders…somehow OID was changed. That part is fixed.

the SMB share is still tits up. trying to map on an iPhone I get “Content Unavailable The folder contents could not be displayed because of an unknown error.” No other details (thanks apple). Still getting the same Windows credential permission denied crap on the windows 11 PC.

Basically, after 15 hours I am back to where I started this morning (albeit with an up to date server and linux PC).

I have read so many threads about Windows credentials but nothing they have suggested fixed my issue…any ideas?

Windows maps the SMB share now. I cannot explain it. Trying to map the drive using GUI “This PC” failed a million times for windows certs. Trying to map in PowerShell failed two dozen times.

Then, for no reason at all entering the ip address in the Run dialog box and the same daggon credentials I had been using all day worked…oh well, that’s fixed. IOS devices are all thats left.

Being an amateur enthusiast with zero background in networking makes this stuff extra hard. iOS is worked out now, the fix was editing the share ACL. I still have no idea how that got changed from three days ago when I accessed it on my phone without issue, but here we are.