I don't know if this counts as hijacking the thread or just confirming the issue you're having, but I've been having an issue with accessing Samba shares on hosts in the LAN using various flavors of Linux(CentOS, ArchLinux, Debian), while I've been able to access the folders just fine on Windows machines. I can get as far as viewing the folders shared by the Asus router, but once I try to actually access the contents of the shared folders, I get blocked out. I can run "smbclient -L ASUS %U just fine as shown below:
Code:
[root@linsanity include]# smbclient -L asus -U%
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.6.25]
Sharename Type Comment
--------- ---- -------
entware-ng.arm Disk sda2's entware-ng.arm in Corsair Voyager 3.0
Media Disk sdc2's media in Verbatim STORE N GO
lib Disk sdc2's lib in Verbatim STORE N GO
sbin Disk sdc2's sbin in Verbatim STORE N GO
root Disk sdc2's root in Verbatim STORE N GO
srv Disk sdc2's srv in Verbatim STORE N GO
proc Disk sdc2's proc in Verbatim STORE N GO
dev Disk sdc2's dev in Verbatim STORE N GO
usr Disk sdc2's usr in Verbatim STORE N GO
mnt Disk sdc2's mnt in Verbatim STORE N GO
bin Disk sdc2's bin in Verbatim STORE N GO
etc Disk sdc2's etc in Verbatim STORE N GO
tmp Disk sdc2's tmp in Verbatim STORE N GO
sys Disk sdc2's sys in Verbatim STORE N GO
var Disk sdc2's var in Verbatim STORE N GO
run Disk sdc2's run in Verbatim STORE N GO
selinux Disk sdc2's selinux in Verbatim STORE N GO
opt Disk sdc2's opt in Verbatim STORE N GO
boot.bak Disk sdc2's boot.bak in Verbatim STORE N GO
home Disk sdc2's home in Verbatim STORE N GO
IPC$ IPC IPC Service (ASUS)
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.6.25]
Server Comment
--------- -------
AAAA
BBBB
CCCC
ASUS ASUS
Workgroup Master
--------- -------
WORKGROUP ASUS
But, when I tried to run "smbclient -L ASUS" from each of the Linux machines per
the advice here, I got this message:
Code:
Server does not support EXTENDED_SECURITY but 'client use spnego = yes and 'client ntlmv2 auth = yes' session setup failed: NT_STATUS_ACCESS_DENIED
I had tried moving up the line "client use spnego = no" in the ASUS's /etc/smb.conf (via /jffs/config/smb.conf) as
suggested here to no avail. That is, the changes to smb.conf stick between boots, but I still can't access the router's shared folders from the few Linux-based hosts on my LAN.
I've definitely exhausted all the options and permutations of the following methods my feeble mind could think of:
-when authenticating to access the shared files, keep the domain name as the default "WORKGROUP"
-when authenticating to access the shared files, clear the domain name field
-log in anonymously
-repeat the above steps except toggling the allow guest login from the web ui
Any help would be much appreciated on either GJW's issue or mine as I imagine they're in a way related or hoping that they are.
