View Full Version : [VU+ Solo SE] Network browser doesn't find shares
I have problems with my Vu+ Solo SE V2 not finding the CIFS or NFS shares on my desktop PC. It can find similar shares on my NAS. The shares or the PC should not be the problem because my Kodi box can find them and it is on the exact same network as the Vu+ and my PC.
The mount that I have created manually works fine so the share is accessible by Vu+ but the network browser doesn't display anything.
Network browser can only find old CIFS or SMBv1 shares, no SMBv2 shares or higher.
A secure configuration however disables anything below SMBv2, as recommended by Microsoft since years.
Not exactly sure about MacOS, but I believe they require at least a better security method than mount.cifs defaults to.
No idea about NFS, but some thoughts:
- NFS4 is very different to NFS3
- Are you sure there is an NFS server?
- Are there any NFS exports at all?
BTW: NFS3 is highly insecure, I wouldn't dare to use it, especially not with an E2 box in the same network.
You can safely connect anything else to the NFS3 server on the E2 box, as there is almost nothing that could be done to make an E2 box more insecure as it already is, but granting an E2 box access to any other system via NFS3 takes the same insecurities to that machine.
Gesendet von meinem SM-N910F mit Tapatalk
Thanks for the reply.
I'm running all the shares from a Windows 7 PC so SMBv1 should still be used, but maybe some security update has disabled it? The NFS shares are handled by haneWIN NFS Server, NFS3 is in use right now since that is the highest level it supports.
Nevertheless, if I have SMBv2 shares on the PC, I should be able to access them by entering all the necessary information without using Network browser? At least the NFS share does work but cannot be seen with the browser. A similar NFS share on my NAS shows up just nice.
I'm running all the shares from a Windows 7 PC so SMBv1 should still be used, but maybe some security update has disabled it?
SMBv1 and older (CIFS) is marked as "deprecated" since June 2013: https://blogs.technet.microsoft.com/josebda/2015/04/21/the-deprecation-of-smb1-you-should-be-planning-to-get-rid-of-this-old-smb-dialect/
"Deprecation" means: Not yet removed, but marked for removal in a later release. Avoid its use.
Microsoft encourages admins to disable SMBv1 for security reasons (https://redmondmag.com/articles/2017/05/18/more-advice-on-disabling-windows-smb-1.aspx ) but hasn't yet disabled or removed it from any Windows or Windows Server version.
So yes, SMBv1 should still be active on your desktop PC, unless you manually disabled it.
The NFS shares are handled by haneWIN NFS Server, NFS3 is in use right now since that is the highest level it supports.
NFS up to NFS3 comes with absolutely no security at all (under realistic home use cases) and it can not even be activated (It simply does not exist).
NFS3 works in the following way:
It exports all files below a certain starting point to any machine matching a specific IP(v4)(-range).
Ownership (root, user1, user2, ...) and file modes (755, 644, ...) are exported 1:1, where in fact user information is exchanged by numeric user id and not the user name.
That means if machine A grants machines B, C, D, ... access to files, they will be accessible for users on B, C, D in exactly the same way as they would on A.
That means the roots of B, C, D are allowed to do really everything to any file/directory on A, no matter who owns them there.
It also means that e.g. user 1000 on C owns any files/directories owned by user 1000 on A, even if user 1000 on A is "snoopy" while it is "mickeymouse" on C.
The "security" of NFS up to NFS3 was based on the assumption (or fact at that time in the eighties), that networks are administrated centrally. A network using NFS would maintain a central user data base synced with all machines (or even kept centrally when using dumb terminals), so that user 1000 would really be "snoopy" on all machines and "mickeymouse" would be 1001 on all machines and nobody else but a real admin would be "root" anywhere. Nobody would bring in "alien" machines into the network.
Nothing of this is true nowadays, your NAS administrates its users independently from your desktop PC, your Raspberry Pi, your E2 box. Any of these machines will have its own root with more or less security against privilege escalation.
Most people will let in friends' smartphones or tablets of which they have no control about the user configuration.
As a matter of fact, security is entirely disabled on E2 boxes, you can log into a terminal session as root without even a password ...
So as soon as any "higher" device exports files/directories to an E2 box, everybody on that E2 box (incl. whoever pwned it) also has full unrestricted access to any exported files on that higher machine, as everybody is root on E2.
To put it simple: An NFS3 server exports files/directories and imports the (in)security concept of the weakest client.
That's why I strongly discourage setting up an NFS3 server on any "valuable" machine (Desktop PC, NAS, ...).
You can however comparable safely import NFS3 exports of the E2 box to such machines using the noexec option, as E2 can not lose any security anymore, it's already 100% insecure.
Short:
1. Don't set up NFS3 servers anywhere
2. Freely use the NFS3 shares of E2 boxes on other machines, but preferably with "noexec" so that files on the E2 box can never be executed on the clients.
Nevertheless, if I have SMBv2 shares on the PC, I should be able to access them by entering all the necessary information without using Network browser? At least the NFS share does work but cannot be seen with the browser. A similar NFS share on my NAS shows up just nice.
Yes.
You can add all types of shares manually to your E2 box using all the options that Linux offers, not being restricted to the small subset which the network browser supports.
I don't know about OpenViX, but at least OpenATV will even backup and restore those manually configured shares on couch flash.
To manually add shares to your E2 box:
1. Make sure you have not added any share using the network browser (They are stored in some non-system config, which would cause E2 to overwrite your system config on every start)
2. Add the shares to /etc/auto.network (For autofs mount) or /etc/fstab (For permanent mount, not recommended for SMB shares on Windows systems)
Example entries for my shares on OpenATV:
/etc/auto.network
Wohnzimmer -fstype=cifs,vers=3.02,sec=ntlmsspi,rw,user=root,pa ss=MYPASS ://vuduo2/Harddisk
Arbeitszimmer -fstype=cifs,vers=3.02,sec=ntlmsspi,rw,user=root,pa ss=MYPASS ://vusolo2se/Harddisk
Testbox -fstype=cifs,vers=3.02,sec=ntlmsspi,rw,user=root,pa ss=MYPASS ://vusolo2/Harddisk
Dokus -fstype=cifs,vers=3.02,sec=ntlmsspi,ro,user=Ziggy\ SpaceRat,pass=MYPASS ://NAS/Dokus
Filme -fstype=cifs,vers=3.02,sec=ntlmsspi,ro,user=Ziggy\ SpaceRat,pass=MYPASS ://NAS/Filme
Porn -fstype=cifs,vers=3.02,sec=ntlmsspi,ro,user=Ziggy\ SpaceRat,pass=MYPASS ://NAS/Porn
TV-Serien -fstype=cifs,vers=3.02,sec=ntlmsspi,ro,user=Ziggy\ SpaceRat,pass=MYPASS ://NAS/TV-Serien
As you can see here,
I'm using SMBv3.02 (Introduced with Windows 8.1 / Windows Server 2012 R2; 3.1.1 as used by Windows 10 / Windows Server 2016 is not supported by all but the very latest Linux kernels) instead of SMBv1 which Linux would default to: vers=3.02
Note:
OpenViX 5.0.x, OpenATV 6.0, ... support vers=2.0 at most when they are the server, only images built from oe-a 4.1 on machines with more than 64MB of flash already support SMBv3 (E.g. OpenATV 6.1, OpenDroid 6.4, ...), so if vers=3.02 fails with some shares, try vers=2.0 for them.
I'm using sec=ntlmsspi
ntlmsspi is the minimum (!) security for current Mac OS shares.
The default value varied over time (= Linux kernel versions) and Network Browser only tries the default.
You should try in this order:
ntlmsspi,ntlmv2i,ntlmssp,ntlmv2,ntlmi,ntlm
Options that will likely not work in OpenViX 5.0.x (All kernels missing CIFS_UPCALL): krb5i,krb5
Ziggy\ SpaceRat
The \ "escapes" the space character between "Ziggy" and "SpaceRat". Windows usernames are likely to contain whitespaces, as they usually consist of christian name + surname.
So if the Windows user is "John Doe", you would add "John\ Doe" here.
I haven't played around with Windows servers using "online" (SkyDrive based) accounts yet. You will probably need to put the email here, but I do not know if you then need the PIN (if set) or the password as password.
//vuduo2 , //vusolo2 , ...
Note that I put the server name in here, not the IP(v4) as Network Browser would.
Multiple benefits:
- Shares work even if the machines have dynamic IPs (Mine get static ones via DHCPv4, SLAAC and partly DHCPv6, but it would work with dynamic assignment as well)
- Entries are simply more readable, as you see the true server here and not its obfuscation by some numeric IP address
- Shares work over IPv6 if available (and will continue to work as people migrate from IPv4-only over Dual Stack to IPv6 in the future)
Thank you very, very much for the informative post. I'm sure it will help others as well, digging up such information is very time-consuming.
I think I need to switch from using NFS shares to using SMB shares as soon as I have the time to go through the whole process. I just need to check which version LibreELEC supports as I have my movies etc. on the NAS and the libraries in Kodi use its NFS shares. I would expect it to be a fairly recent one since it seems to use a recent Linux kernel.
I think I need to switch from using NFS shares to using SMB shares as soon as I have the time to go through the whole process. I just need to check which version LibreELEC supports as I have my movies etc. on the NAS and the libraries in Kodi use its NFS shares. I would expect it to be a fairly recent one since it seems to use a recent Linux kernel.
Actually to be more precise:
An NFS share on a NAS or server is no problem, as long as you do not export "/" but only subdirectories with no important files inside.
E.g. if your NAS has the subdirectory "/share/Video" with only videos inside and the NAS only exports "/share/video", the worst two things someone pwning the E2 box could do would be to put evil programs inside that tree (That's why you should import using noexec, so that they can not be executed) or to delete the stuff.
But if you export "/", anyone on the E2 box could modify any file on the server (NAS), incl. the user database in /etc/passwd , /etc/shadow, /etc/groups ...
That's one of the reasons why full Linux distros put the home for user root into /root rather than /home/root ...
That takes some of the risk out of exporting "/home" to clients:
If some security escalation takes place on any NFS client (And just to remind: E2 is configured to escalate anyone by default), the escalated user could only destroy all regular users' files, but not those of root, as his home /root is outside the export. But if there is any known "sudoer"-user, there are possible ways to take the escalation to the server again ...
There is one problem I did not mention about the SMB shares however:
If you password protect the shares, the clients needs to login ... however that also means that anyone pwning the E2 box can read the plaintext passwords out of /etc/fstab or /etc/auto.network
So actually to be safe, you would need to create some underprivileged (i.e. no shell/GUI access) user on the Windows/Samba server and use that for the share.
But if you export "/", anyone on the E2 box could modify any file on the server (NAS), incl. the user database in /etc/passwd , /etc/shadow, /etc/groups ...Only if someone is crazy enough to set up there NAS with the NFS server running under the root user.
So actually to be safe, you would need to create some underprivileged (i.e. no shell/GUI access) user on the Windows/Samba server and use that for the share.
Wouldn't the basic Windows "Guest" user do here? I could set up things so that the user Guest would have R/W permissions to the folder which I use as an HDD replacement in Vu+.
I rechecked things and I use Samba shares on the NAS for Kodi libraries. On the PC, I have one directory (C:\Share) exported via NFS with the readonly parameter. Under that folder, I have symbolic links to all my folders with media in them. I suppose that if I want to use SMB, I have to share each of the linked folders separately. With NFS, there is no need for that.
If I disable SMB1 on the NAS, I cannot mount the share from there on the Vu+. If I re-enable it, the shared folder is available normally. I suspect the same happens on the PC as well.
As I said: Network Browser can only find SMBv1 shares and it creates entries only suitable for SMBv1 shares.
If you create the mounts manually, you can mount with params as needed.
I mount all shares using SMBv3.02 ...
Gesendet von meinem SM-N910F mit Tapatalk
Wouldn't the basic Windows "Guest" user do here? I could set up things so that the user Guest would have R/W permissions to the folder which I use as an HDD replacement in Vu+.
I rechecked things and I use Samba shares on the NAS for Kodi libraries. On the PC, I have one directory (C:\Share) exported via NFS with the readonly parameter. Under that folder, I have symbolic links to all my folders with media in them. I suppose that if I want to use SMB, I have to share each of the linked folders separately. With NFS, there is no need for that.Yes, guest will do.
No, junctions are not an NFS feature, they are a file system feature.
The stuff inside my "Porn", "Movies", "TV series" and "Documentary" shares is distributed across five (!) external RAID5 enclosures, re-united by linking the appropriate folders into folders on my internal HDD.
One example:
Porn\BBW\Clips
is also available as
Porn\Clips\BBW
and actually the genre BBW is just a junction to
C:\mnt\External 3\Porn\BBW.
So there is a myriad of junctions on my HDD and they are all accessible without a problem through SMB.
Gesendet von meinem SM-N910F mit Tapatalk
As I said: Network Browser can only find SMBv1 shares and it creates entries only suitable for SMBv1 shares.
If you create the mounts manually, you can mount with params as needed.
I mount all shares using SMBv3.02 ...
Tried that all right.. I just retried adding an entry in the auto.network file but the share refuses to open.
Tried that all right.. I just retried adding an entry in the auto.network file but the share refuses to open.
Depending on how you edited /etc/auto.network, autofs might refuse to load that config.
It must not be world readable in order to be acceptable for autofs.
If that is the reason, then
chmod 600 /etc/auto.network
might help.
Nope, still the same problem. The share cannot be opened.
No idea, unless I get to see the /etc/auto.network you created (Obfuscate passwords)
It looks like this:
# automounter configuration
PC -fstype=nfs,rw,nolock,tcp,nfsvers=3,rsize=8192,wsiz e=8192,timeo=14,soft 192.168.0.50:/q/VuPlus
testi -fstype=cifs,vers=3.02,sec=ntlmsspi,ro,user=vu,pass =***** ://TEHOMYLLY/vu
The NFS one is what I use now as the recording folder. The other one is what I've tested, and I have verified that the share itself is fine.
It looks like this:
# automounter configuration
PC -fstype=nfs,rw,nolock,tcp,nfsvers=3,rsize=8192,wsiz e=8192,timeo=14,soft 192.168.0.50:/q/VuPlus
testi -fstype=cifs,vers=3.02,sec=ntlmsspi,ro,user=vu,pass =***** ://TEHOMYLLY/vu
The NFS one is what I use now as the recording folder. The other one is what I've tested, and I have verified that the share itself is fine.
Does the forum software add those useless whitespaces?
Try:
testi -fstype=cifs,vers=2.00,sec=ntlmsspi,ro,user=vu,pass =***** ://TEHOMYLLY/vu
(Not all kernels support SMBv3)
You can also check if "TEHOMYLLY" resolves at all:
nslookup TEHOMYLLY
if it doesn't, either use the server's correct hostname or its IP.
Does the forum software add those useless whitespaces?
Try:
testi -fstype=cifs,vers=2.00,sec=ntlmsspi,ro,user=vu,pass =***** ://TEHOMYLLY/vu
(Not all kernels support SMBv3)
Setting vers=2.00 did the trick :)
One more thing - where can I automount that directory as hdd?
Setting vers=2.00 did the trick :)
You can try higher versions after upgrading to the forthcoming major release of OpenViX
We are working on kernel tuning in oe-a 4.1 but OpenViX 5.0.x is based on oe-a 4.0, where no more changes happen.
One more thing - where can I automount that directory as hdd?
That's one of the aspects in E2 I have never understood.
Some things are achieved in a totally overcomplicated way, the "NAS as HDD recplacement" is one of them. Instead of just mounting everything "as-is" and symlinking physical mounts (A la /media/sandisk-cruzer or /media/sda1 ) to logical mounts (Like /media/hdd, /media/usb), there are quirks cluttered across all parts, the base system and E2, just to make the NAS appear as /media/hdd).
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.