SMB is a file sharing protocol and, as such, it is sometime left open to the internet for, well, sharing files.
However, this is a very bad idea. Compared to simpler protocol as FTP or WebDAV, which basically have very small GET/PUT interfaces and are entirely implemented in isolated userspace processes, SMB is a much more complex protocol, deeply ...
If the accepted answer gives you this error;
System error 1219 has occurred.
Multiple connections to a server or shared resource by the same user, using
more than one user name, are not allowed. Disconnect all previous connections
to the server or shared resource and try again.
You'll need to first remove the existing shares. If you're in a hurry, this ...
I did find a way to do this. Hopefully this helps someone else looking for the same information.
On the server, open a powershell then enter this command:
Get-SmbSession | Select-Object -Property ClientComputerName,ClientUserName,Dialect
For more verbose output:
Get-SmbSession | Select-Object -Property *
the below steps have helped me resolve this exact issue on a number of occasions:
Login to the samba server.
Run a "smbstatus".
Find the pid of the process that has the lock on the file
in the third section of the output.
Verify that it matches the expected user and hostname
in the first and second sections of the smbstatus output.
Run "ps -ef" and see ...
You basically have it.
User vs Machine vs Share Authentication
SMB/CIFS bases access on user credentials of some sort (whether they be KRB tokens, user/password pairs, or what have you) per session where each session is mapped to one user. NFSv3 uses host-based authentication where all users of a given remote machine share the same connection. SMB/CIFS, ...
NFS: it has a partial support for sparse file. Basically, it supports creating a sparse file but, when reading, the file is expanded to include zeroes. This means that, while you can create a sparse file via NFS, when reading back that very same file the in-transit network data will include any zeroes found on the original file. A simple test show that ...
On my network - as of this writing (things do change) - smbtree is my preferred solution. It asks for your password (meaning your Samba password), and then it gives a nicely detailed list that includes netbios name, available shares, and the share description.
nmblookup, on the other hand, does not list all the available shares on my network. I do not know ...
This really piqued my interest. I was able to replicate your findings in my lab with the same pattern of results that you describe. I used Procmon to to try to see what changes are made and almost gave up until I saw the following:
That shows lsass.exe (Local Security Authority) writing to the local SAM and making a change(s) to the built-in Guest account (...
I believe that doing this will allow users to delete files from their
desktop/documents folder etc, and still provide a way to restore from
the recycle bin.
I can confirm that with Folder Redirection, Recycle Bin still works on Windows 2008R2. Probably works on 2012 as well. But Folder Redirection and WinXP clients for example, Recycle Bin does not work....
Yes, NFS 4.2 fully supports sparse files (see this canonical document and this presentation).
Prior to NFS 4.2, the NFS client/server model supported sparse files in the sense that the API supported all POSIX file operations. This meant that writing sparse files on a server which supported sparse files on the backing file system resulted in a sparse ...
You're probably missing the fact that Offline Files must be enabled on the client side in order for files and programs accessed from the Share to be cached offline. Additionally, only files and programs that have been opened from the Share are made available offline. Simply accessing the Share doesn't cache it's contents in the Offline Files cache.
Durable handles are part of SMB 2.0
Resilient handles are part of SMB 2.1
Persistent handles are part of SMB 2.2 which is now called SMB3
My main references for the following are:
and although this was originally for Samba3, it has more details:
Durable file ...
If you have Windows 8.1 or 2012, you can use the PowerShell cmdlet Get-SmbConnection for that.
To interpret the answer (copied and pasted from here):
SMB 1 - Windows 2000
SMB 2 - Windows Server 2008 and WIndows Vista SP1
SMB 2.1 - Windows Server 2008 R2 and Windows 7
SMB 3.0 - Windows Server 2012 and Windows 8
In general any ransomware can encrypt anything the infected user has access to, like any other malware can write to anywhere using the permissions of the account running it. That doesn't equal it becoming active for other users, but it can affect all shares the user has access to.
Prevent with virus protection & firewall, as usual.
Just don't do it. If anyone asks you to do it, I would strongly recommend telling them no and running away fast.
You could technically provide this kind of service over a VPN, but if it's over any significant distance over WAN it's almost certainly going to perform like total garbage.
There are far superior services to accomplish remote and local file ...
The NAS is a 2U Synology Rack set up in SMB 2.0 and higher mode. Plenty of space on the share (and NAS). The server is Windows 2012 R2
SMB 2.xx is your problem. You need SMB 3.xx to allow Hyper-V running VMs from your file share.
This configuration worked for me: 137/UDP, 138/UDP, 139/TCP and 445/TCP. Source and additional information at: http://www.icir.org/gregor/tools/ms-smb-protocols.html.
So these are the iptables rules for my Samba server:
# The router doesn't need SMB access.
-A INPUT -s 192.168.1.1 -p udp --dport 137 -j REJECT
-A INPUT -s 192.168.1.1 -p udp --dport 138 -j ...
Linux or Windows or whatever?
Linux: smbclient … -c "rm $filename" – but be aware of filenames with unusual characters: you may have to escape or quote $filename.
Alternate solution: simply mount the filesystem(s), and access the files with the usual command-line tools.
"smb 445 tcp filtered" does not means that something is listening on port 445. From nmap man page:
Filtered. means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed
SMB protocol handshake is always SMB, for backwards compatibility. The connection is upgraded later on. If you deny all packets with SMB headers, no connection will be established.
You cann see this in a successful protocol negotiation:
NextCloud has WebDAV functionality / integration and can replicate data between off-site <-> on-premises in the way you want. This is no open source / free software, but you might want to give it a try.
P.S. I have nothing to do with this company, just in case :)
The short answer is: Meh.
On a file "Move" (AKA Cut and Paste) between the same share it will simply change the index on the file server (pretty much instant).
Unfortunately when you try to move between two different shares (Even on the same file server) or do a "copy" operation it does pull the data through the client PC (slow).
On any "move" operation ...
You can usually get a pretty good idea of this just by opening "Share and Storage Management" on your 2008R2 server, and over in the right pane you'll see "Manage Sessions" and "Manage Open Files". You might try that first.
If that fails, you might try Process Explorer from Sysinternals. Do a handle search for the file name. The process that has an open ...
The reason is most likely that Sever 2003 R2 uses SMB 1.0, While Server 2008 R2 uses SMB 2.1. The linked article there has a table which shows what version of the protocol you'll be able to use with which client-server combinations. A connection to Server 2003 R2 will always be limited to SMB 1.0.
The newer versions of the SMB protocol include many ...
Is there any reason? I will leave that up to you.
It can be done. Open port 445 and config SMB and you can access your shared folders over the internet similar to how you would do it over your local network.
It's going to be very slow because the protocol was not designed to work over such environment.
There are known security risks. IP restriction could ...
No. Leave the minimum number of ports exposed to the Internet. If you need to use SMB for something (transferring files with a trusted other party, with authentication and timestamps on every action taken), then set up a VPN for them to connect to before making an SMB connection.
EDIT 14Jan2019:- please see the new accepted answer instead, it contains the official fix instead of this work-around.
I'm posting an answer in the hope others find it easier to find here than I did on the original site:
Rolling back the updates solves the problem, however I can also confirm that the registry edit below resolved the problem in all cases that ...
In samba version 4, nmblookup '*' no longer works; it only gives the local server. It used to work in samba version 3.
Now, you have to use nmblookup WORKGROUP, which as Kurt mentioned, only returns servers in workgroup WORKGROUP.