Setting Share Permissions & ACL's remotely to ubuntu 16.04 Samba file server via Windows Server 2012 r2
By
OpSupport,
in HOW TO & FAQ Guides
-
Recently Browsing 0 members
No registered users viewing this page.
-
Similar Content
-
By +BudMan
So I have recently fired up a synology ds918+ running DSM 6.2-23648 (beta)
So when I was running windows I got full speed both up and down from shares 113MBps.. With smb3 multichannel I was seeing 220 up and down.. I have a thread showing this.
Well my move to the nas vs windows running on a esxi host has pushed me to move my main desktop to linux.. I will prob only run windows as VM to help users with stuff, etc. Just because I am stuck with it at work doesn't mean I have to run it at home any more.
So running linux mint 18.3.. All was going good until tried to mount my shares.. Seems something odd with latest kern or something and since not using smbv1 had to mount via cmd line, will add to fstab once all working as it should. So no problem I got my shares mounted and working..
sudo mount -t cifs //192.168.9.10/share /home/budman/nas/share -o username=budman,vers=3,uid=budman
Copy a large file down and speeds look fine...
But when pushing a file to the share.. it max out at like 14MBps
While I can find all kinds of info about slow speeds, nothing that makes much sense for tweaks to smb.conf and such.. Or specific on changes in how mounting it?
I don't use samba much.. Any suggestions here? Anyone seen this sort of thing - seems very odd.. Its sure not a disk issue this is running off 860 EVO brand new SSD.. If I boot back to my windows SSD I get full speeds..
I move a lot of files back and forth between my nas and pc.. So if can not work this out have to go back to running windows until I do. I can give NFS a try vs smb... But seems odd linux mint doesn't come with nfs out of the box?
edit: Using file station to upload the file gives me 72MBps... So clearly its something in the in the samba on linux..
edit2: Guess just use NFS... because with that seeing full speed.. WTF??/
-
By +MJK
A flaw in Intel AMT can leave your laptop exposed to attackers
by Muhammad Jarir Kanji
Following on the heels of the revelations of the Meltdown and Spectre vulnerabilities plaguing decades of Intel's processors, a new flaw in the Active Management Technology (AMT) has left Intel in even more hot water among the cybersecurity community.
The new flaw targets laptops, especially those powered by Intel's enterprise-focused vPro processors, and exploits the remote access monitoring and maintenance tools provided by AMT to gain total control over the machine. Relatively easy to implement, the attack is also not impeded in any way by BIOS or BitLocker passwords, TPM pins, or login credentials.
In order to carry out the attack, an individual would need physical access to the machine. The way it works is by rebooting the machine and entering the boot menu. While you would normally need the BIOS password in order to perform any hijinks at this point, using Intel's Managment Engine BIOS Extension (MEBx) can allow an attacker to login in with a simple 'admin' login that is the default.
The attacker can then proceed by, "changing the default password, enabling remote access and setting AMT’s user opt-in to 'None'" to effectively compromise the machine, according to F-Security researcher Harry Sintonen. He continues, "Now the attacker can gain access to the system remotely, as long as they’re able to insert themselves onto the same network segment with the victim (enabling wireless access requires a few extra steps)."
The ease with which the attack can be carried out is of particular concern, with Sintonen warning users,
That physical access to the system is required is also not a large hindrance since the target of the attack are laptops, which are mobile by their nature and therefore easily accessible outside of secure environments. The process also takes under a minute, meaning the shortest of distractions could be enough for someone to tamper with your laptop.
As of now, the only ways of mitigating the danger is to change the AMT password from its default 'admin' setting to something harder to guess - or to just disable the feature entirely.
Source: F-Secure via PC Gamer
-
By vishal1082
Google finally updates its Samba client for Android; disables SMBv1, adds support for SMBv3
by Vishal Laul
Just over two weeks ago, Google released a Samba client for Android out of the blue and without much fuss, bringing users the ability to mount Windows shares and conveniently move files. Unfortunately, it wasn't quite an ideal solution due to the perplexingly exclusive support for SMBv1.
The SMBv1 protocol is vulnerable to exploits discovered by the NSA and released by The Shadow Brokers earlier this year; the WannaCry ransomware abused the protocol to propagate through networks in over seventy countries a few months ago and was followed by the Petya/NotPetya ransomware – using the same exploit – soon after.
Today, Google has released an update for the Samba client, disabling support for SMBv1 by default and enabling support for SMBv2 and SMBv3 protocols.
The SMBv2 and SMBv3 versions of the protocol offer a few extra security features and do not share the same vulnerabilities as SMBv1.
Since the client is open-source, we can see that the change, in fact, happened more than a week ago, and was brought upon due to an “urge from users” – it just took Google this long to push an update for the app on the Play Store.
However, it seems Google still has some work to do; of the 154 total reviews on the Play Store, the Samba client has received 60 one-star reviews, with only 45 five-star reviews, giving it a score of a mere 2.8. The most common complaint seems to be about a clunky interface, limited features, and the inability to unmount a share.
The client may not be very feature-rich, but with the fatal vulnerability fixed, it is at least more secure.
Source: Github, Google Play Store (Android Samba Client)
-
By vishal1082
Google releases a Samba client for Android, only supports the vulnerable SMBv1 protocol
by Vishal Laul
A couple of days ago, out of the blue, Google released an open-source Samba client for Android, bringing users the convenience of being able to easily mount and access files over a network using the SMB protocol.
In its description, Google states that the app is a “direct port of the Samba client,” and thus supports its entire feature set. Unfortunately, Google fails to mention that the app only supports the extremely vulnerable SMBv1 networking protocol.
As tested by Android Police’s Corbin Davenport, the app simply refuses to connect if a Samba share has SMBv1 disabled.
Microsoft’s Ned Pyle also chimes in to put emphasis on the risk SMBv1 possesses for users on Android:
The ‘WannaCry’ ransomware that propagated through networks in over 70 countries a couple of months ago abused the SMBv1 protocol; this was followed by Petya/NotPetya ransomware just last week, which brought several organizations in Ukraine and the rest of Europe to a halt.
SMBv2 and SMBv3 versions of the protocol do not share these same vulnerabilities and offer quite a few extra (and perhaps necessary) security features as well.
While Google has been quite enthusiastic about pointing out “crazy bad” flaws and vulnerabilities in software other than its own, it seems that the company has neglected its own software. This comes at a time when organizations are moving away from SMBv1, with Microsoft going as far as creating a list of old and new software that still relies on the vulnerable protocol.
Source: Google Play Store (Android Samba Client) via Android Police
-
By neoamigo
Hello,
To help others in my university Litemanagerfree used for monitoring and control, and you?
-
Recommended Posts