Accessing Legacy Windows (SMB/Samba) Shares...
Accessing Legacy Windows (SMB/Samba) Shares...
Hi All,
I am running the latest (2015-08-20 15:11) beta firmware on my T3 and new T4. On the T4 I find that I can not access SMB (Windows) shares coming from Windows XP or other older legacy systems. The mount happens but the file system is inaccessible. It appears that the underlying code is generating an error along the lines of "Operation not permitted" for these older shares.
This can be worked around by adding the a mount option "sec=ntlm" to the current mount options. This allows the newer code to make a valid connection to older style Windows shares.
I don't know if this is actually a bug or simply technology moving on but I believe the above suggestion rates as a hack or trick that may help others to get around the issue.
Regards,
Ian.
I am running the latest (2015-08-20 15:11) beta firmware on my T3 and new T4. On the T4 I find that I can not access SMB (Windows) shares coming from Windows XP or other older legacy systems. The mount happens but the file system is inaccessible. It appears that the underlying code is generating an error along the lines of "Operation not permitted" for these older shares.
This can be worked around by adding the a mount option "sec=ntlm" to the current mount options. This allows the newer code to make a valid connection to older style Windows shares.
I don't know if this is actually a bug or simply technology moving on but I believe the above suggestion rates as a hack or trick that may help others to get around the issue.
Regards,
Ian.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Definitely in the category of "hack/useful tip" for a legacy (unsupported by anyone) operating system. I am not sure whether it is a good idea to include that mount option by default. If you would like to summarise the pros and cons of doing so, I'm open to making changes to the default. The basic rule of thumb being that enabling any legacy options should not compromise / have negative impact on systems that are using current / supported operating systems. "If in doubt, leave it out."
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Hi PeterU,
The T3 is running the same version of beta firmware as the T4 and doesn't appear to have the problem. The builds of Samba appear to be the same. The only obvious difference is the kernel. The T3 is using "Linux t3 3.6.0 #1 SMP Thu Aug 6 23:46:04 AEST 2015 mips GNU/Linux" while the T4 uses "Linux t4 3.14.2 #1 SMP Thu Jul 23 01:49:02 AEST 2015 mips GNU/Linux". Are there any build differences between the two?
From the limited testing I performed I had issues connecting to Windows XP machines and ReadyNAS NAS boxes. Connections to Windows 7 appeared to work okay. I think all the NAS units I tried were *not* running the latest firmware (if it ain't broken don't fix it ).
I wouldn't advocate setting this option by default until we fully understand the problem and any possible security implications. An obvious first question could be does *anyone* else see this problem?
Having a bit of a Google around ('smb mount problem "Operation not supported"' then also added "sec=") found the following - and lots more:
https://bugzilla.samba.org/show_bug.cgi?id=8914 (search the page for "Operation not supported")
http://unix.stackexchange.com/questions ... -smbclient
http://askubuntu.com/questions/354235/f ... oing-wrong
http://ubuntuforums.org/showthread.php?t=947858
https://lists.samba.org/archive/samba/2 ... 64407.html
In most/all cases a "sec=" option appears to be required to fix the problem.
Regards,
Ian.
The T3 is running the same version of beta firmware as the T4 and doesn't appear to have the problem. The builds of Samba appear to be the same. The only obvious difference is the kernel. The T3 is using "Linux t3 3.6.0 #1 SMP Thu Aug 6 23:46:04 AEST 2015 mips GNU/Linux" while the T4 uses "Linux t4 3.14.2 #1 SMP Thu Jul 23 01:49:02 AEST 2015 mips GNU/Linux". Are there any build differences between the two?
From the limited testing I performed I had issues connecting to Windows XP machines and ReadyNAS NAS boxes. Connections to Windows 7 appeared to work okay. I think all the NAS units I tried were *not* running the latest firmware (if it ain't broken don't fix it ).
I wouldn't advocate setting this option by default until we fully understand the problem and any possible security implications. An obvious first question could be does *anyone* else see this problem?
Having a bit of a Google around ('smb mount problem "Operation not supported"' then also added "sec=") found the following - and lots more:
https://bugzilla.samba.org/show_bug.cgi?id=8914 (search the page for "Operation not supported")
http://unix.stackexchange.com/questions ... -smbclient
http://askubuntu.com/questions/354235/f ... oing-wrong
http://ubuntuforums.org/showthread.php?t=947858
https://lists.samba.org/archive/samba/2 ... 64407.html
In most/all cases a "sec=" option appears to be required to fix the problem.
Regards,
Ian.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Seems the consensus is get used to it. The power that be have decreed NTLM is now a legacy protocol.
God I really miss Cobol, it was really good way to provide useful and harmless employment for the great unwashed. Now that great unwashed try their hand at system programming and royally fsck the world over.
God I really miss Cobol, it was really good way to provide useful and harmless employment for the great unwashed. Now that great unwashed try their hand at system programming and royally fsck the world over.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Hi IanB,
So what is your suggestion for Beyonwiz? Should the "sec=ntlm" be added by default or should the kernel minimum security level be adjusted to the previous level?
Regards,
Ian.
So what is your suggestion for Beyonwiz? Should the "sec=ntlm" be added by default or should the kernel minimum security level be adjusted to the previous level?
Regards,
Ian.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
I'm inclined to take the pragmatic approach and steer towards maximum compatibility (and thus better user experience), as long as doing so does not prevent proper interoperability with current and emerging OSes.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Hi PeterU,
I would welcome an ease of use decision.
Will you do it as a mount command option, as posted, or lower the minimum security threshold?
Regards,
Ian.
I would welcome an ease of use decision.
Will you do it as a mount command option, as posted, or lower the minimum security threshold?
Regards,
Ian.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
My preferred approach for this particular fix would be to put it as close to the user (and as visible) as is practical. That probably implies changing the default mount options that are presented in the GUI. This gives the clued users a mechanism to change the option.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
A tick box in the mount options screen for "legacy shares"?
I've seen plenty of other options like that in BIOSs and the like that simply say "enable this if you run Windows XP".
I've seen plenty of other options like that in BIOSs and the like that simply say "enable this if you run Windows XP".
Logitech Harmony Ultimate+Elite RCs
Beyonwiz T2/3/U4/V2, DP-S1 PVRs
Denon AVR-X3400h, LG OLED65C7T TV
QNAP TS-410 NAS, Centos File Server (Hosted under KVM)
Ubiquiti UniFi Managed LAN/WLAN, Draytek Vigor130/Asus RT-AC86U Internet
Pixel 4,5&6, iPad 3 Mobile Devices
Beyonwiz T2/3/U4/V2, DP-S1 PVRs
Denon AVR-X3400h, LG OLED65C7T TV
QNAP TS-410 NAS, Centos File Server (Hosted under KVM)
Ubiquiti UniFi Managed LAN/WLAN, Draytek Vigor130/Asus RT-AC86U Internet
Pixel 4,5&6, iPad 3 Mobile Devices
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Hi MrQuade,
Regards,
Ian.
Nice!MrQuade wrote:A tick box in the mount options screen for "legacy shares"?
Or older NASs! (Like my ReadyNAS units.)MrQuade wrote:I've seen plenty of other options like that in BIOSs and the like that simply say "enable this if you run Windows XP".
Regards,
Ian.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Hi,
Thinking about MrQuade's tick box suggestion a bit more and I think he is onto a very good idea. Perhaps all the common mount options should be removed from the "Mount options" setting and made a list of tick box selections. The list of options can change based on the type of mount selected. Each option could then be accompanied by a text description that describes the option and why it could or should be used. The "Mount options" entry could be renamed "Additional mount options" and be put at the end of the list of tick boxes for advanced users who know exactly what options they want to use. (The description text could list all the options the version of Samba in use can support.)
This would make the whole mount system easier for the non technical user to manage while still allowing "power" users to fully control the option.
Regards,
Ian.
Thinking about MrQuade's tick box suggestion a bit more and I think he is onto a very good idea. Perhaps all the common mount options should be removed from the "Mount options" setting and made a list of tick box selections. The list of options can change based on the type of mount selected. Each option could then be accompanied by a text description that describes the option and why it could or should be used. The "Mount options" entry could be renamed "Additional mount options" and be put at the end of the list of tick boxes for advanced users who know exactly what options they want to use. (The description text could list all the options the version of Samba in use can support.)
This would make the whole mount system easier for the non technical user to manage while still allowing "power" users to fully control the option.
Regards,
Ian.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Sounds like a big job, but if you want to have a go, I'll review the pull-request. Of course, such a massive change will take longer to review and merge.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Hi PeterU,
Tell me about it. Some of my pull requests have been waiting for well over a month!
I will have a look at this after I finish my Menu.py renovation and get my OverlayHD skin ready for public beta testing.
Regards,
Ian.
Tell me about it. Some of my pull requests have been waiting for well over a month!
I will have a look at this after I finish my Menu.py renovation and get my OverlayHD skin ready for public beta testing.
Regards,
Ian.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Geez, you guys always seem to reach for the sledge hammer. Stringing a whole lot of poxy application code together to fix bad system defaults imposed by Nazi XP killers.
A more sensible default should have been 0x87, thus allowing NTLMSSP as a new addition. But some fool really wants to make Windows XP and all the other software that emulates it not work without a lot of research and special hacks.
I tested on my T3 thus :-
Perhaps a T4 owner can test and report, I suggest trying both values 0x7 and 0x87.
From Re: [opensuse] CIFS - where/how is /proc/fs/cifs/SecurityFlags set?
Apparently the policy change is in the kernel driver, fs/cifs/cifsglob.h The old SecurityFlags default was 0x7, the new is 0x85.IanB wrote:Seems the consensus is get used to it. The power that be have decreed NTLM is now a legacy protocol.
A more sensible default should have been 0x87, thus allowing NTLMSSP as a new addition. But some fool really wants to make Windows XP and all the other software that emulates it not work without a lot of research and special hacks.
I tested on my T3 thus :-
Code: Select all
cat /proc/fs/cifs/SecurityFlags
0x7
# Everything works as per normal
>/proc/fs/cifs/SecurityFlags echo 0x85
cat /proc/fs/cifs/SecurityFlags
0x85
# Thing become FUBAR, as expected.
>/proc/fs/cifs/SecurityFlags echo 0x7
cat /proc/fs/cifs/SecurityFlags
0x7
# Everything works as per normal again
From Re: [opensuse] CIFS - where/how is /proc/fs/cifs/SecurityFlags set?
Re: [opensuse] CIFS - where/how is /proc/fs/cifs/SecurityFlags set?
From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
Date: Tue, 07 Jan 2014 13:54:47 -0600
Message-id: <52CC5B87.6030806@suddenlinkmail.com>
On 01/06/2014 10:13 PM, Andrey Borzenkov wrote:
By whom?
fs/cifs/cifsglob.h:#define CIFSSEC_DEF (CIFSSEC_MAY_SIGN |
CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP)
Andrey,
Thank you! That was it. If you check 'cat /proc/fs/cifs/SecurityFlags' you
will find 0x85 which is the current default:
CIFSSEC_MAY_SIGN 0x00001
CIFSSEC_MAY_NTLMV2 0x00004
CIFSSEC_MAY_NTLMSSP 0x00080 /* raw ntlmssp with ntlmv2 */
-------
0x00085
for older version it was most likely:
CIFSSEC_MAY_SIGN 0x00001
CIFSSEC_MAY_NTLM 0x00002
CIFSSEC_MAY_NTLMV2 0x00004
-------
0x00007
--
David C. Rankin, J.D.,P.E.
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx
Re: Accessing Legacy Windows (SMB/Samba) Shares...
The big job isn't in making it work by using different default options. The big job I was referring to is the apparent desire to completely rework the user interface, which IMHO is an unrelated task. But, if there are people willing to go into the effort of improving the user interface, I'm not going to stand in their way. As long as the design makes sense and the code to support it is of reasonable quality, I'm happy to take contributions.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Hi PeterU,
But if IanB's solution is a fast fix to the underlying issue then why not go for it. UI improvements can come later.
Regards,
Ian.
But if IanB's solution is a fast fix to the underlying issue then why not go for it. UI improvements can come later.
Regards,
Ian.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Hi,
I tried the commands Ian suggested on my T4 and obtained some surprising results:
It looks like something might be very wrong at a kernel level.
Regards,
Ian.
I tried the commands Ian suggested on my T4 and obtained some surprising results:
Code: Select all
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x85
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 0x7
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 0
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x85
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 1
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x5005
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 2
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x0
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 3
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 4
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x0
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 5
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 0x85
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 133
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 0x87
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
root@t4:~# >/proc/fs/cifs/SecurityFlags echo 135
root@t4:~# cat /proc/fs/cifs/SecurityFlags
0x1
Regards,
Ian.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Some archaeology :-
The CIFS SecurityFlags default changed at the initial kernel version 3.8 to 0x81=(CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMSSP) and eventually changed to 0x85=(CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP) some time between then and now.
Also the parsing code behind /proc/fs/cifs/SecurityFlags changed at the same time. (see below)
Apparently if one does ">/proc/fs/cifs/cifsFYI echo 1" then extra debug info will be written to dmesg so we might get a clue as to why we cannot set desirable values to /proc/fs/cifs/SecurityFlags.
The 0x5005 for 1 and 0x85 for 0 values are obviously from the Boolean parse code at the top, " bv ? CIFSSEC_MAX : CIFSSEC_DEF;"
Possibly the cifs_debug.c code gets borked and then gets fixed again between 3.7 and now, but both code snippets below look good.
PeterU what cifs_debug.c did you build the T4 kernel with?
/fs/cifs/cifs_debug.c previous version 3.7
/fs/cifs/cifs_debug.c latest
The CIFS SecurityFlags default changed at the initial kernel version 3.8 to 0x81=(CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMSSP) and eventually changed to 0x85=(CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP) some time between then and now.
Also the parsing code behind /proc/fs/cifs/SecurityFlags changed at the same time. (see below)
Apparently if one does ">/proc/fs/cifs/cifsFYI echo 1" then extra debug info will be written to dmesg so we might get a clue as to why we cannot set desirable values to /proc/fs/cifs/SecurityFlags.
The 0x5005 for 1 and 0x85 for 0 values are obviously from the Boolean parse code at the top, " bv ? CIFSSEC_MAX : CIFSSEC_DEF;"
Possibly the cifs_debug.c code gets borked and then gets fixed again between 3.7 and now, but both code snippets below look good.
PeterU what cifs_debug.c did you build the T4 kernel with?
/fs/cifs/cifs_debug.c previous version 3.7
Code: Select all
581 static ssize_t cifs_security_flags_proc_write(struct file *file,
582 const char __user *buffer, size_t count, loff_t *ppos)
583 {
....
593 if (copy_from_user(flags_string, buffer, count))
594 return -EFAULT;
595
596 if (count < 3) {
597 /* single char or single char followed by null */
598 c = flags_string[0];
599 if (c == '' || c == 'n' || c == 'N') {
600 global_secflags = CIFSSEC_DEF; /* default */
601 return count;
602 } else if (c == '1' || c == 'y' || c == 'Y') {
603 global_secflags = CIFSSEC_MAX;
604 return count;
605 } else if (!isdigit(c)) {
606 cERROR(1, "invalid flag %c", c);
607 return -EINVAL;
608 }
609 }
610 /* else we have a number */
611
612 flags = simple_strtoul(flags_string, NULL, 0);
613
614 cFYI(1, "sec flags 0x%x", flags);
Code: Select all
619 static ssize_t cifs_security_flags_proc_write(struct file *file,
620 const char __user *buffer, size_t count, loff_t *ppos)
621 {
...
633 if (copy_from_user(flags_string, buffer, count))
634 return -EFAULT;
635
636 if (count < 3) {
637 /* single char or single char followed by null */
638 c = flags_string[0];
639 if (strtobool(&c, &bv) == 0) {
640 global_secflags = bv ? CIFSSEC_MAX : CIFSSEC_DEF;
641 return count;
642 } else if (!isdigit(c)) {
643 cifs_dbg(VFS, "Invalid SecurityFlags: %s\n",
644 flags_string);
645 return -EINVAL;
646 }
647 }
648
649 /* else we have a number */
650 rc = kstrtouint(flags_string, 0, &flags);
651 if (rc) {
652 cifs_dbg(VFS, "Invalid SecurityFlags: %s\n",
653 flags_string);
654 return rc;
655 }
656
657 cifs_dbg(FYI, "sec flags 0x%x\n", flags);
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Let's just go with the mount flag, path of least resistance.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Hi PeterU,
Regards,
Ian.
But most user inconvenience.peteru wrote:Let's just go with the mount flag, path of least resistance.
Regards,
Ian.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
I assume it was this one bcm7425-linux-3.14.2-20141120.tgzIanB wrote:PeterU what cifs_debug.c did you build the T4 kernel with?
Hmmm!peteru wrote:Let's just go with the mount flag, path of least resistance.
I organised a session with a friends T4 to investigate further, and yes IanSav's results above when trying to set /proc/fs/cifs/SecurityFlags does for many cases indeed result either 0x0 or 0x1 values. Most interesting is that the cases that do work correctly are when setting the secure level CIFSSEC_MUST_* values. i.e. CIFSSEC_MUST_NTLM, 0x02002.
And looking at the code, we find that when compiled without the CONFIG_CIFS_WEAK_PW_HASH config option the flags do indeed get nuked at line 619 of cifs_debug.c
cifsglob.h line 1423
#define CIFSSEC_MUST_LANMAN 0
cifs_debug.c line 618
else if ((*flags & CIFSSEC_MUST_LANMAN) == CIFSSEC_MUST_LANMAN)
____*flags = CIFSSEC_MUST_LANMAN;
Yes (*flags & 0 == 0) is always true, so *flags=0; always happens.
So the solution would appear to be to include the CONFIG_CIFS_WEAK_PW_HASH option in the next kernel build. And it would also be helpful to include CONFIG_CIFS_DEBUG to allow dmesg output.
Then we should be setting /proc/fs/cifs/SecurityFlags to 0xB7 to maximise support for all possible SMB servers.
Confirm version and build options :- Yes 2.02 and no Feature at all.
Code: Select all
# cat /proc/fs/cifs/DebugData
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 2.02
Features:
Active VFS Requests: 0
Servers:
Code: Select all
/*
* Ensure that if someone sets a MUST flag, that we disable all other MAY
* flags except for the ones corresponding to the given MUST flag. If there are
* multiple MUST flags, then try to prefer more secure ones.
*/
static void
cifs_security_flags_handle_must_flags(unsigned int *flags)
{
unsigned int signflags = *flags & CIFSSEC_MUST_SIGN;
if ((*flags & CIFSSEC_MUST_KRB5) == CIFSSEC_MUST_KRB5)
*flags = CIFSSEC_MUST_KRB5;
else if ((*flags & CIFSSEC_MUST_NTLMSSP) == CIFSSEC_MUST_NTLMSSP)
*flags = CIFSSEC_MUST_NTLMSSP;
else if ((*flags & CIFSSEC_MUST_NTLMV2) == CIFSSEC_MUST_NTLMV2)
*flags = CIFSSEC_MUST_NTLMV2;
else if ((*flags & CIFSSEC_MUST_NTLM) == CIFSSEC_MUST_NTLM)
*flags = CIFSSEC_MUST_NTLM;
else if ((*flags & CIFSSEC_MUST_LANMAN) == CIFSSEC_MUST_LANMAN)
*flags = CIFSSEC_MUST_LANMAN;
else if ((*flags & CIFSSEC_MUST_PLNTXT) == CIFSSEC_MUST_PLNTXT)
*flags = CIFSSEC_MUST_PLNTXT;
*flags |= signflags;
}
Code: Select all
#ifdef CONFIG_CIFS_WEAK_PW_HASH
#define CIFSSEC_MUST_LANMAN 0x10010
#define CIFSSEC_MUST_PLNTXT 0x20020
#ifdef CONFIG_CIFS_UPCALL
#define CIFSSEC_MASK 0xBF0BF /* allows weak security but also krb5 */
#else
#define CIFSSEC_MASK 0xB70B7 /* current flags supported if weak */
#endif /* UPCALL */
#else /* do not allow weak pw hash */
#define CIFSSEC_MUST_LANMAN 0
#define CIFSSEC_MUST_PLNTXT 0
#ifdef CONFIG_CIFS_UPCALL
#define CIFSSEC_MASK 0x8F08F /* flags supported if no weak allowed */
#else
#define CIFSSEC_MASK 0x87087 /* flags supported if no weak allowed */
#endif /* UPCALL */
#endif /* WEAK_PW_HASH */
Re: Accessing Legacy Windows (SMB/Samba) Shares...
I don't understand why you would find it preferable to make changes to the kernel rather than add an option to the user interface. Maybe I don't have the whole picture here. My understanding is that legacy SMB servers (as well as modern SMB servers) will work if the CIFS filesystem is passed the ntlm mount option. Let's just add that to the default mount options that enigma2 presents for CIFS mounts and we're done.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Because the code in the cifs_debug.c you used to build your latest kernel is broken!
Adding workaround code to enigma to fix a kernel driver bug when I have given you the kernel driver fix is just plain wrong. And hacking the client mount options will defeats the security policy when the kernel cifs driver is finally fixed.
You are supposed to be able to set /proc/fs/cifs/SecurityFlags to implement the security policy appropriate to your needs, but we cannot because the cifs_debug.c you used to build your latest kernel is broken!
Also the the CIFS driver as built does not support LanMan authentication, so even if you do a sec=lanman on your mount command it will not work.
Setting the kernel config option CONFIG_CIFS_WEAK_PW_HASH solves both problems, it includes LanMan authentication and avoids the set /proc/fs/cifs/SecurityFlags bug.
Also you are supposed to control kernel logging of the CIFS driver with /proc/fs/cifs/cifsFYI but without the kernel config option CONFIG_CIFS_DEBUG nothing happens!
All this works properly and correctly on the older CIFS driver used on the T3. In order to maintain functionality we now need to enable some config options. The current development path of the cifs driver seems to be a little broken.
Adding workaround code to enigma to fix a kernel driver bug when I have given you the kernel driver fix is just plain wrong. And hacking the client mount options will defeats the security policy when the kernel cifs driver is finally fixed.
You are supposed to be able to set /proc/fs/cifs/SecurityFlags to implement the security policy appropriate to your needs, but we cannot because the cifs_debug.c you used to build your latest kernel is broken!
Also the the CIFS driver as built does not support LanMan authentication, so even if you do a sec=lanman on your mount command it will not work.
Setting the kernel config option CONFIG_CIFS_WEAK_PW_HASH solves both problems, it includes LanMan authentication and avoids the set /proc/fs/cifs/SecurityFlags bug.
Also you are supposed to control kernel logging of the CIFS driver with /proc/fs/cifs/cifsFYI but without the kernel config option CONFIG_CIFS_DEBUG nothing happens!
All this works properly and correctly on the older CIFS driver used on the T3. In order to maintain functionality we now need to enable some config options. The current development path of the cifs driver seems to be a little broken.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
CONFIG_CIFS_WEAK_PW_HASH enables LanMan (OS/2 and Win 95 level security), which is not what IanSav was after. He was after NTLM for Win XP level of compatibility. He also said that adding the "sec=ntlm" option did solve the issue.
I really don't see much point in rebuilding the kernel for 20+ year old operating system compatibility (OS/2 and Win95) when the fix for (the obsolete, but still deployed) WinXP can be achieved by adding a mount option.
What I am concerned about is compatibility with current versions of OSX and Windows. From what I gather, by forcing sec=ntlm, you will break connectivity to OSX SMB server, which will only speak sec=ntlmssp.
At this stage, I would like both WinXP and OSX users to test the behaviour they see when they:
1. Supply no additional mount options
2. Supply "sec=ntlm" mount option
3. Supply "sec=ntlmv2" mount option
4. Supply "sec=ntlmssp" mount option
I am hoping that "sec=ntlmv2" might be a middle ground that works in all cases, but I need empirical evidence. I don't run any Windows or OSX systems.
I really don't see much point in rebuilding the kernel for 20+ year old operating system compatibility (OS/2 and Win95) when the fix for (the obsolete, but still deployed) WinXP can be achieved by adding a mount option.
What I am concerned about is compatibility with current versions of OSX and Windows. From what I gather, by forcing sec=ntlm, you will break connectivity to OSX SMB server, which will only speak sec=ntlmssp.
At this stage, I would like both WinXP and OSX users to test the behaviour they see when they:
1. Supply no additional mount options
2. Supply "sec=ntlm" mount option
3. Supply "sec=ntlmv2" mount option
4. Supply "sec=ntlmssp" mount option
I am hoping that "sec=ntlmv2" might be a middle ground that works in all cases, but I need empirical evidence. I don't run any Windows or OSX systems.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
There are no differences between the CIFS configuration options supplied to the kernel. However, the default in mainline kernel versions prior to v3.8 was sec=ntlm. In v3.8, the default was changed to sec=ntlmssp.IanSav wrote:The T3 is running the same version of beta firmware as the T4 and doesn't appear to have the problem.
...
Are there any build differences between the two?
Re: Accessing Legacy Windows (SMB/Samba) Shares...
NO! CONFIG_CIFS_WEAK_PW_HASH will bypass the bug that is stopping us setting /proc/fs/cifs/SecurityFlags to values other than 0 (illegal), 1, 0x85 and 0x?00?, the LanMan (OS/2 and Win 95 level security) is an incidental bonus. The other missing option CONFIG_CIFS_DEBUG should always be enabled so /proc/fs/cifs/cifsFYI can turn on the debug output.peteru wrote:CONFIG_CIFS_WEAK_PW_HASH enables LanMan (OS/2 and Win 95 level security), which is not what IanSav was after. He was after NTLM for Win XP level of compatibility. He also said that adding the "sec=ntlm" option did solve the issue.
I really don't see much point in rebuilding the kernel ....
It is becoming pretty obvious your answer really is "I really don't want to rebuild the kernel because it hard work." Fair enough, just say it and I will stop wasting my time.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Yes both build have no special CIFS options.peteru wrote:There are no differences between the CIFS configuration options supplied to the kernel. However, the default in mainline kernel versions prior to v3.8 was sec=ntlm. In v3.8, the default was changed to sec=ntlmssp.IanSav wrote:The T3 is running the same version of beta firmware as the T4 and doesn't appear to have the problem.
...
Are there any build differences between the two?
No! The default for prior versions was Security mask 0x7 which is PacketSign, NTLM, NTLMV2. And logging was available.
The new default Security mask is 0x85 is PacketSign, NTLMV2, NTLMSSP. And logging is not available.
You cannot strictly map Security mask options to mount options. The Security mask options give a list of what is allowed to be tried automatically.
The mount options specify one single option to explicitly attempt. i.e. NTLM only or NTLMv2 only
Pretty obvious how this is going to turn out.peteru wrote:At this stage, I would like both WinXP and OSX users to test the behaviour they see when they:
1. Supply no additional mount options
2. Supply "sec=ntlm" mount option
3. Supply "sec=ntlmv2" mount option
4. Supply "sec=ntlmssp" mount option
I am hoping that "sec=ntlmv2" might be a middle ground that works in all cases, but I need empirical evidence. I don't run any Windows or OSX systems.
1. no additional mount options -- servers that allow ntlmv2 or ntlmssp will connect.
WinXp no, >=Vista yes, things with suitable smb.conf option yes else no.
2. "sec=ntlm" mount option -- servers that allow ntlm will connect.
WinXp yes, >=Vista(without reg hack) no, things with suitable smb.conf option yes else no.
3. "sec=ntlmv2" mount option -- servers that allow ntlmv2will connect.
WinXp no, >=Vista yes, things with suitable smb.conf option yes else no.
4. "sec=ntlmssp" mount option -- servers that allow ntlmssp will connect.
WinXp no, >=Vista yes, things with suitable smb.conf option yes else no.
I believe the latest OSX default only permits ntlmssp connections, but it is apparently configurable.
Really the CIFS people are a pack of bastards, its none of their business which connections to allow or deny, that is the job of the server. Clients should just work (Tm.).
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Hi PeterU,
I would like it to just work!
It is silly to allow users of the client to make a network connection and then have to find out why the connection appeared to work but no data is available. Then make users have to work out and understand the mechanics of the machine to which they are trying to connect. Then to work out what "sec=" option they may need at the client to make things work properly. This seems even more silly if the client end can be made to "just work" simply by having the builder set an option or two when building the system.
Security requirements really should be forced by the server and be optional at the client. If the server wants to share its connections via a clear text password then why should the client *force* a far more secure protocol. If the server doesn't care then why should the client? We are talking about home network connections where, in many cases, even usernames and passwords are not a desirable security measure. This is not a confidential corporate or business network with confidential data that *needs* to be protected. Even if it was it would be the servers that enforce the protection and not the clients.
Regards,
Ian.
I would like it to just work!
It is silly to allow users of the client to make a network connection and then have to find out why the connection appeared to work but no data is available. Then make users have to work out and understand the mechanics of the machine to which they are trying to connect. Then to work out what "sec=" option they may need at the client to make things work properly. This seems even more silly if the client end can be made to "just work" simply by having the builder set an option or two when building the system.
Security requirements really should be forced by the server and be optional at the client. If the server wants to share its connections via a clear text password then why should the client *force* a far more secure protocol. If the server doesn't care then why should the client? We are talking about home network connections where, in many cases, even usernames and passwords are not a desirable security measure. This is not a confidential corporate or business network with confidential data that *needs* to be protected. Even if it was it would be the servers that enforce the protection and not the clients.
Regards,
Ian.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
No. Rebuilding the kernel with a different config is a lot less work than changing enigma2. But, all the arguments you presented so far indicate that it's not the right approach. The Beyonwiz kernel has the same CIFS configuration as all the other enigma2 boxes out there. You have not presented a compelling argument for changing that configuration. On the other hand, IanSav's suggestion of supplying sec=ntlm seems like the best solution all around. The outstanding question is what effect will this have on OSX and other modern operating systems?IanB wrote:It is becoming pretty obvious your answer really is "I really don't want to rebuild the kernel because it hard work." Fair enough, just say it and I will stop wasting my time.
Well, in my book, that's completely arse about approach. If there is a bug in processing the flags, then a patch to fix that bug is a lot more preferable than turning on unrelated options just for their side effects. I don't really see an urgent need for such a patch. From my understanding, compatibility with WinXP can be achieved just by specifying sec=ntlm mount option to CIFS.IanB wrote:CONFIG_CIFS_WEAK_PW_HASH will bypass the bug that is stopping us setting /proc/fs/cifs/SecurityFlags to values other than 0 (illegal), 1, 0x85 and 0x?00?, the LanMan (OS/2 and Win 95 level security) is an incidental bonus.
This is arguable too. In general, I would agree that a full blown server or desktop system with plenty of horsepower will benefit from having debug enabled. However, on a resource constrained embedded system, one has to be careful about enabling such things. At this stage we seem to have the root cause of WinXP incompatibility identified and a solution has been proposed. Let's establish the effectiveness of the proposed solution and it's effect on OSX and Win10.IanB wrote:The other missing option CONFIG_CIFS_DEBUG should always be enabled so /proc/fs/cifs/cifsFYI can turn on the debug output.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
I composed the above message last night / early this morning, but did not post it. It appears that in the meantime both Ians posted replies. It also appears that IanB has finally started to make some arguments that may be technically compelling. I will study those in more detail.
As an aside, it is not helpful to use emotionally charged language or aggressive tone. Calling people who work hard on implementing the solution "a pack of bastards" is not on.
As an aside, it is not helpful to use emotionally charged language or aggressive tone. Calling people who work hard on implementing the solution "a pack of bastards" is not on.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
If you read the cifs lists you see they are indeed working very hard with the goal to break default XP support and require special builds to access legacy systems under the guise of it is insecure therefore it should not be allowed. Okay to be fair not everybody, some are actually just trying to get packet signing and ntlmssp working properly, others not so much.peteru wrote:As an aside, it is not helpful to use emotionally charged language or aggressive tone. Calling people who work hard on implementing the solution "a pack of bastards" is not on.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
If you would rather a patch, easy, just delete 4 lines, 618 to 621 of cifs_debug.c
P.S. the CONFIG_CIFS_DEBUG options cost almost nothing until you echo 1 > /proc/fs/cifs/cifsFYI and that functionality used to be the default.
P.P.S and yes various enigma builds are starting to have all sorts of samba/cifs problems as they move to later kernel environments.
P.S. the CONFIG_CIFS_DEBUG options cost almost nothing until you echo 1 > /proc/fs/cifs/cifsFYI and that functionality used to be the default.
P.P.S and yes various enigma builds are starting to have all sorts of samba/cifs problems as they move to later kernel environments.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
I will apply this patch to fix the handling of the MUST flags:
On top of that, I'll also turn on NTLM as part of the defaults:
I will turn on CONFIG_CIFS_DEBUG=y as well. At least for the next round of betas, which will be out after the current beta turns into a full official release.
Code: Select all
From 7a1ceba071709d11271ebd921310b5a18404dd33 Mon Sep 17 00:00:00 2001
From: Niklas Cassel <niklas.cassel@axis.com>
Date: Thu, 22 Jan 2015 14:16:34 +0100
Subject: cifs: fix MUST SecurityFlags filtering
If CONFIG_CIFS_WEAK_PW_HASH is not set, CIFSSEC_MUST_LANMAN
and CIFSSEC_MUST_PLNTXT is defined as 0.
When setting new SecurityFlags without any MUST flags,
your flags would be overwritten with CIFSSEC_MUST_LANMAN (0).
Signed-off-by: Niklas Cassel <niklass@axis.com>
Signed-off-by: Steve French <steve.french@primarydata.com>
diff --git a/fs/cifs/cifs_debug.c b/fs/cifs/cifs_debug.c
index 9c56ef7..7febcf2 100644
--- a/fs/cifs/cifs_debug.c
+++ b/fs/cifs/cifs_debug.c
@@ -606,9 +606,11 @@ cifs_security_flags_handle_must_flags(unsigned int *flags)
*flags = CIFSSEC_MUST_NTLMV2;
else if ((*flags & CIFSSEC_MUST_NTLM) == CIFSSEC_MUST_NTLM)
*flags = CIFSSEC_MUST_NTLM;
- else if ((*flags & CIFSSEC_MUST_LANMAN) == CIFSSEC_MUST_LANMAN)
+ else if (CIFSSEC_MUST_LANMAN &&
+ (*flags & CIFSSEC_MUST_LANMAN) == CIFSSEC_MUST_LANMAN)
*flags = CIFSSEC_MUST_LANMAN;
- else if ((*flags & CIFSSEC_MUST_PLNTXT) == CIFSSEC_MUST_PLNTXT)
+ else if (CIFSSEC_MUST_PLNTXT &&
+ (*flags & CIFSSEC_MUST_PLNTXT) == CIFSSEC_MUST_PLNTXT)
*flags = CIFSSEC_MUST_PLNTXT;
*flags |= signflags;
Code: Select all
Subject: cifs: Enable NTLM security to provide backwards compatibility with WinXP.
diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index c0f3718..81dcca3 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -1431,7 +1431,7 @@ require use of the stronger protocol */
#define CIFSSEC_MUST_SEAL 0x40040 /* not supported yet */
#define CIFSSEC_MUST_NTLMSSP 0x80080 /* raw ntlmssp with ntlmv2 */
-#define CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP)
+#define CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLM | CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP)
#define CIFSSEC_MAX (CIFSSEC_MUST_SIGN | CIFSSEC_MUST_NTLMV2)
#define CIFSSEC_AUTH_MASK (CIFSSEC_MAY_NTLM | CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_LANMAN | CIFSSEC_MAY_PLNTXT | CIFSSEC_MAY_KRB5 | CIFSSEC_MAY_NTLMSSP)
/*
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Fair enough, pity this was such an effort.
Also glad you are hacking the driver default SecurityFlags to 0x87. => Just works! (Tm.)
And thanks for enabling the debug.
Also glad you are hacking the driver default SecurityFlags to 0x87. => Just works! (Tm.)
And thanks for enabling the debug.
Last edited by IanB on Tue Sep 01, 2015 17:34, edited 1 time in total.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
I realise this fix is just for authentication and security, but would any of the extra debugging data assist in debugging the TCP coalescing issues I have seen with modern Windows (7+) playing recordings over Samba using VLC?
Logitech Harmony Ultimate+Elite RCs
Beyonwiz T2/3/U4/V2, DP-S1 PVRs
Denon AVR-X3400h, LG OLED65C7T TV
QNAP TS-410 NAS, Centos File Server (Hosted under KVM)
Ubiquiti UniFi Managed LAN/WLAN, Draytek Vigor130/Asus RT-AC86U Internet
Pixel 4,5&6, iPad 3 Mobile Devices
Beyonwiz T2/3/U4/V2, DP-S1 PVRs
Denon AVR-X3400h, LG OLED65C7T TV
QNAP TS-410 NAS, Centos File Server (Hosted under KVM)
Ubiquiti UniFi Managed LAN/WLAN, Draytek Vigor130/Asus RT-AC86U Internet
Pixel 4,5&6, iPad 3 Mobile Devices
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Lol Title.
This is my favourite support request: " I understand it's legacy (old/outdated/due for replacement/unsupported), but I just want it to work.."
Followed by my new second favourite: " my BYOD (Bring Your Own Device [ie self managed]) gadget isn't working right, can a techie come configure it properly for me please...?"
Thanks for teh giggles.
This is my favourite support request: " I understand it's legacy (old/outdated/due for replacement/unsupported), but I just want it to work.."
Followed by my new second favourite: " my BYOD (Bring Your Own Device [ie self managed]) gadget isn't working right, can a techie come configure it properly for me please...?"
Thanks for teh giggles.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
So, now that the latest beta has these updates, can I please get a report as to the state of legacy networking?
Were the fixes effective? Can I consider this issue resolved?
Were the fixes effective? Can I consider this issue resolved?
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Hi PeterU,
In summary, the fixes improve the situation but not fully / effectively.
The debugging and logging now works properly.
While I was party to the testing that was done I am not fully confident that I understood everything that happened. I believe that if the 0x80 bit is set in the mount bitmap then the cifs code breaks and does not allow the mount to work if the specific 0x80 mount fails. If that bit is not set the mounts work. From my understanding the code is failing to continue with the less secure mounts if the 0x80 mount fails. Given that the default mount mask includes the 0x80 bit then all mounts still fail by default.
Apparently this is another bug in the cifs code and not a problem with the patches you applied.
Hopefully IanB can chime in with more details and information when he is available.
Regards,
Ian.
In summary, the fixes improve the situation but not fully / effectively.
The debugging and logging now works properly.
While I was party to the testing that was done I am not fully confident that I understood everything that happened. I believe that if the 0x80 bit is set in the mount bitmap then the cifs code breaks and does not allow the mount to work if the specific 0x80 mount fails. If that bit is not set the mounts work. From my understanding the code is failing to continue with the less secure mounts if the 0x80 mount fails. Given that the default mount mask includes the 0x80 bit then all mounts still fail by default.
Apparently this is another bug in the cifs code and not a problem with the patches you applied.
Hopefully IanB can chime in with more details and information when he is available.
Regards,
Ian.
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Logging now works. Fixed!
The /proc/fs/cifs/SecurityFlags can now be set to any valid value. Fixed!
With the 0x2, CIFSSEC_MAY_NTLM , bit included connections to XP boxes now work correctly as before. i.e. 0x85 -> 0x87 Fixed!
Having the 0x80, CIFSSEC_MAY_NTLMSSP, bit breaks connection to the previous version 3.5.xx of Samba servers, because that 3.5.xx version implements a broken first attempt implementation of NtlmSSP. It works just well enough to bypass the early fail and move on to NtlmV2 logic. Setting SecurityFlags to 0x7 or mounting with sec=ntlmv2 or sec=ntlm works for this version. Older versions of samba that do not implement NtlmSSP, do correctly fail down to a lower security and "Just Works(Tm!)".
Tested against ReadyNas with samba versions, 3.5.8, 3.5.15 and 3.5.22.
The T4 was running samba 3.6.24.
Suggest running with SecurityFlags set to 0x7 might be the best "Just Works(Tm!)" solution while Samba 3.5.xx is still moderately popular.
The /proc/fs/cifs/SecurityFlags can now be set to any valid value. Fixed!
With the 0x2, CIFSSEC_MAY_NTLM , bit included connections to XP boxes now work correctly as before. i.e. 0x85 -> 0x87 Fixed!
Having the 0x80, CIFSSEC_MAY_NTLMSSP, bit breaks connection to the previous version 3.5.xx of Samba servers, because that 3.5.xx version implements a broken first attempt implementation of NtlmSSP. It works just well enough to bypass the early fail and move on to NtlmV2 logic. Setting SecurityFlags to 0x7 or mounting with sec=ntlmv2 or sec=ntlm works for this version. Older versions of samba that do not implement NtlmSSP, do correctly fail down to a lower security and "Just Works(Tm!)".
Tested against ReadyNas with samba versions, 3.5.8, 3.5.15 and 3.5.22.
The T4 was running samba 3.6.24.
Suggest running with SecurityFlags set to 0x7 might be the best "Just Works(Tm!)" solution while Samba 3.5.xx is still moderately popular.
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
Re: Accessing Legacy Windows (SMB/Samba) Shares...
It's had no effect on my main problem with Samba which is that the Network browser scan on the T series doesn't find the Samba server in my router.
But then I don't think that the changes should have made any difference to that.
But then I don't think that the changes should have made any difference to that.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
Re: Accessing Legacy Windows (SMB/Samba) Shares...
What does :-
smbclient -L <Samba_ip_address>
Password: (blank)
show?
smbclient -L <Samba_ip_address>
Password: (blank)
show?
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Code: Select all
root@beyonwizt3:/media/hdd/logs# smbclient -L 192.168.178.1
WARNING: The security=share option is deprecated
Enter root's password:
dos charset 'CP850' unavailable - using ASCII
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]
Sharename Type Comment
--------- ---- -------
Hellespont Disk
IPC$ IPC IPC Service (FRITZ!Box)
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]
Server Comment
--------- -------
Workgroup Master
--------- -------
root@beyonwizt3:/media/hdd/logs#
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
Re: Accessing Legacy Windows (SMB/Samba) Shares...
The anonymous login to the Samba server in your router does not have quite enough access to enumerate it's world.
Compare the output for my 3.0.37 samba server (xxx is elided) :-
Note my populated Server and Workgroup sections, yours are empty.
Compare when you use this:-
# smbclient -U <valid user> -L <Samba_ip_address>
Password: <valid password>
In your smb.conf what have you got your "guest account =" set to, mine is set to "plebb" a user I created for this purpose (no password, /bin/true shell).
Compare the output for my 3.0.37 samba server (xxx is elided) :-
Code: Select all
# smbclient -L 192.168.xxx.xxx
Password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]
Sharename Type Comment
--------- ---- -------
DiskRO Disk The Disk
IPC$ IPC IPC Service (xxxxx)
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]
Server Comment
--------- -------
BEYONWIZ-T32 SettopBox beyonwiz-t32 network services
BEYONWIZ-T31 SettopBox beyonwiz-t31 network services
Linux
DX7300
Workgroup Master
--------- -------
WORKGROUP DX7300
Compare when you use this:-
# smbclient -U <valid user> -L <Samba_ip_address>
Password: <valid password>
In your smb.conf what have you got your "guest account =" set to, mine is set to "plebb" a user I created for this purpose (no password, /bin/true shell).
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
Re: Accessing Legacy Windows (SMB/Samba) Shares...
xxx = elided username
Code: Select all
root@beyonwizt3:/media/hdd/logs# smbclient -L 192.168.178.1 -U xxx
WARNING: The security=share option is deprecated
Enter xxx's password:
dos charset 'CP850' unavailable - using ASCII
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]
Sharename Type Comment
--------- ---- -------
Hellespont Disk
IPC$ IPC IPC Service (FRITZ!Box)
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]
Server Comment
--------- -------
Workgroup Master
--------- -------
root@beyonwizt3:/media/hdd/logs#
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Well that is certainly strange, the servers own name should at least appear in the server list. I could believe the workgroup list might be empty if there is no workgroup membership defined, but "Domain=[WORKGROUP]" is stated.
Can you fiddle with the smb.conf or is this a turn key router?
Does the router run a nmdb or is it one of those micro-hacked smbd only configs?
Can you fiddle with the smb.conf or is this a turn key router?
Does the router run a nmdb or is it one of those micro-hacked smbd only configs?
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Its a turnkey router, but I think that with the current firmware I can telnet in and have a look round.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
Re: Accessing Legacy Windows (SMB/Samba) Shares...
IanB wrote:...
In your smb.conf what have you got your "guest account =" set to, mine is set to "plebb" a user I created for this purpose (no password, /bin/true shell).
Code: Select all
[global]
workgroup = WORKGROUP
server string = FRITZ!Box
syslog = 0
username map = /var/tmp/users.map
encrypt passwords = true
passdb backend = smbpasswd
obey pam restrictions = yes
socket options = TCP_NODELAY
unix charset = UTF8
max stat cache size = 64
mangled names = no
bind interfaces only = yes
interfaces = lan
security = user
guest account = root
null passwords = yes
time server = yes
[Hellespont]
path = /var/media/ftp
read only = no
username = xxx, yyy, zzz # not their real names
valid users = xxx, yyy, zzz # not their real names
create mask = 0777
force create mode = 0777
directory mask = 0777
force directory mode = 0777
Apologies about the (slash)etc/passwd rubbish, but if I actually put a '/' in there, the stupid forum software accuses me of mounting an RFI/LFI file inclusion attack and won't let me post. Even more stupid is that it's apparently OK with /etc/shadow where the actually interesting stuff is stashed
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
Re: Accessing Legacy Windows (SMB/Samba) Shares...
Looks pretty much okay.
Is a nmbd running?
Slightly strange "guest account = root", but we tried with a valid user/pass so it's not that.
Is a nmbd running?
Slightly strange "guest account = root", but we tried with a valid user/pass so it's not that.
-
- Wizard God
- Posts: 32714
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
Re: Accessing Legacy Windows (SMB/Samba) Shares...
smdb, not nmdb
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV