is it possible to to mount a Win10Pro shared folder on DNS-323 ?

[Zoli]

I want to build a ransomware-safe backup solution. 

My idea is: 

My Windows machine will have a folder called "bkp" with important docs which will be archived regularly. That folder will be shared to a specific user on windows machine called "bkpuser"

My DNS-323 should mount "bkp" folder and by using rsync the files will be archived on DNS-323's HDD in a different folder. (before running rsync I would compare the content of a ransomware-trap doc on both side to prevent destroying good files with encrypted files in case of ransomware virus infection.)

The problem is:

I cannot mount Windows share. It seems like some incompatibility issue. (from my android phone I could reach "bkp" folder from Total Commander with "bkpuser")

On Windows (turn windows features on/off panel) SMB1.0/CIFS File sharing support is turned on. And I checked: EnableSMB1Protocol : True; EnableSMB2Protocol : True

1) I've created a /mnt/winbkp (777 root/root)  folder on DNS-323

2a) after running 

mount -t cifs -o username=bkpuser,password=psw //192.168.1.123/bkp /mnt/winbkp 

mounting does not give error message but when I want to run ls command I get this:

ls /mnt/winbkp

ls: can't open '/mnt/winbkp': Value too large for defined data type

2b) I have tried smb2.0 and 3.0 as well:

In these cases the error message is coming immediately after running mount:

mount -t cifs -o vers=2.0,username=bkpuser,password=psw //192.168.1.123/bkp /mnt/winbkp

or

mount -t cifs -o vers=3.0,username=bkpuser,password=psw //192.168.1.123/bkp /mnt/winbkp

mount error(22): Invalid argument

Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

mount: mounting //192.168.1.123/bkp on /mnt/winbkp failed: Invalid argument

I am using Alt-F 1.0 with kernel 4.4.86

samba-small package is installed by default (but I have tried it with samba,samba-modules, samba-extra installed and result was the same)

Using smb2.0 or 3.0 would be the best but I would be happy with 1.0 now too.

Can anybody give an advice what should I try, please?

(or, if it is not possible should I create an sftp server on windows instead?  NSF server is not an option on Win10pro)

[João Cardoso]

On Sunday, 5 April 2020 12:29:18 UTC+1, Zoli wrote:

I want to build a ransomware-safe backup solution. 

My idea is: 

My Windows machine will have a folder called "bkp" with important docs which will be archived regularly. That folder will be shared to a specific user on windows machine called "bkpuser"

My DNS-323 should mount "bkp" folder and by using rsync the files will be archived on DNS-323's HDD in a different folder. (before running rsync I would compare the content of a ransomware-trap doc on both side to prevent destroying good files with encrypted files in case of ransomware virus infection.)

The problem is:

I cannot mount Windows share. It seems like some incompatibility issue. (from my android phone I could reach "bkp" folder from Total Commander with "bkpuser")

On Windows (turn windows features on/off panel) SMB1.0/CIFS File sharing support is turned on. And I checked: EnableSMB1Protocol : True; EnableSMB2Protocol : True

1) I've created a /mnt/winbkp (777 root/root)  folder on DNS-323

2a) after running 

mount -t cifs -o username=bkpuser,password=psw //192.168.1.123/bkp /mnt/winbkp 

mounting does not give error message but when I want to run ls command I get this:

ls /mnt/winbkp

ls: can't open '/mnt/winbkp': Value too large for defined data type

I can partially reproduce that:

[root@DNS-325]# mount -t cifs -ousername="Joao Cardoso",password=xxxx //MONO/Users /mnt/cifs; echo $?
mount error(112): Host is down

Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

mount: mounting //MONO/Users on /mnt/cifs failed: Host is down
32

It must be kernel related, as it succeeds with kernel 4.14.78 if I add the "noserverino" option.

Also, /proc/fs/cifs/DebugData says that SMB-2.08 is supported by the cifs 4.4.86 kernel module, while SMB-2.10 is supported by the 4.14.78 kernel

on kernel 4.14.78: adding 'vers=2.1,noserverino' to mount options makes it work.

[root@DNS-320L]# mount -t cifs
//MONO/Users on /mnt/cifs type cifs (rw,mand,relatime,vers=2.1,cache=strict,username=Joao\040Cardoso
,domain=,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.105,file_mode=0755,dir_mode=0755,soft,noun
ix,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

2b) I have tried smb2.0 and 3.0 as well:

In these cases the error message is coming immediately after running mount:

mount -t cifs -o vers=2.0,username=bkpuser,password=psw //192.168.1.123/bkp /mnt/winbkp

or

mount -t cifs -o vers=3.0,username=bkpuser,password=psw //192.168.1.123/bkp /mnt/winbkp

mount error(22): Invalid argument

yes, looks like 'vers' is not accepted on 4.4.86

 

Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

mount: mounting //192.168.1.123/bkp on /mnt/winbkp failed: Invalid argument

I am using Alt-F 1.0 with kernel 4.4.86

samba-small package is installed by default (but I have tried it with samba,samba-modules, samba-extra installed and result was the same)

Using smb2.0 or 3.0 would be the best but I would be happy with 1.0 now too.

having to enable SMB1 for a anti ransomware system does not look right

If your window box has smb1 really enabled, then 'smbtree -N' should list shares

 

Can anybody give an advice what should I try, please?

No clues...

 

(or, if it is not possible should I create an sftp server on windows instead?

win-10 now has native ssh, doesn't it also have sshd?

[Zoli]

2a) after running 

mount -t cifs -o username=bkpuser,password=psw //192.168.1.123/bkp /mnt/winbkp 

mounting does not give error message but when I want to run ls command I get this:

ls /mnt/winbkp

ls: can't open '/mnt/winbkp': Value too large for defined data type

I can partially reproduce that:

[root@DNS-325]# mount -t cifs -ousername="Joao Cardoso",password=xxxx //MONO/Users /mnt/cifs; echo $?
mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount: mounting //MONO/Users on /mnt/cifs failed: Host is down
32

 

I have seen "Host is down" message when I have disabled smb1.0 on Windows and added vers=1.0 option to mount command. 

 

It must be kernel related, as it succeeds with kernel 4.14.78 if I add the "noserverino" option.

Also, /proc/fs/cifs/DebugData says that SMB-2.08 is supported by the cifs 4.4.86 kernel module, while SMB-2.10 is supported by the 4.14.78 kernel

on kernel 4.14.78: adding 'vers=2.1,noserverino' to mount options makes it work.

The noserverino option has solved the 2a) error ("Value too large for defined data type") so SMB-1.0 is working now at least. :)

I don't understand why vers=2.08 is not working for me if vers=1.0 is working and you tell that my kernel supports SMB-2.08 

Do you think in the not so far future kernel version 4.14.78 will be available on DNS-323?

 

(or, if it is not possible should I create an sftp server on windows instead?

win-10 now has native ssh, doesn't it also have sshd

Thanks for checking the issue and advices, I will check that has the win10 sshd or not..

[Zoli]

@João Cardoso, thank you again for the help and the sshd idea.

I want to put some summary here for those people who wants to SSH  from ALT-F linux  to Windows machine and wants to initiate rsync not on Windows but on Linux side.

(in archiving problems the windows ->linux direction seems more frequent than  linux ->windows as I found during googleing however linux->windows direction is more safe I think)

I hope I do not skip any important step.

==================== ( ALT-F Linux => ssh => Windows  -  and rsync via ssh connection ) ===================================

To-do on Windows:

- install opensshd on windows

  URL=https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse

- check that both of openssh services are up and running (I missed 1st this and spent some hours to set up different keys/different users for nothing)

- public/private user key pair is needed for passwordless ssh. As on ALT-F I could not create RSA keys (there is no ssh-keygen)

  I have run it on windows (with current user, not with "nasuser"). The the generated files are id_rsa and id_rsa.pub

  a) both of them should be moved to the NAS into /home/nasuser/.ssh dir

  b) public key is need to be placed on windows machine in /users/nasuser/.shh dir (or where is the %userprofile% of nasuser)

     but not as is its content need to be added to authorized_keys file there. If there is no such a file just rename

id_rsa.pub to authorized_keys

- install cygwin on windows machine and install rsync package in it

-it is needed because when NAS connects via ssh to windows box , rsync will run on windows machine (at least it is missing if not installed)

-and if the directory to be archived is not on C: drive you can use cygwin's drive path.

for example if windows path is like  e:\Docs then rsync will reach it by this path: /cygdrive/e/Docs

To-do on NAS:

-check SSH connection with password (windows user's pw)  1st (my windows pc's local IP addr is 192.168.1.2)

 

  ssh nas...@192.168.1.2

 if connection is not working, it is probably an access problem. Create a windows firewall rule ( type in searchbar:  "firewall" and open windows defender firewall and set  "Allow and app or feature" or a special rule: TCP inbound port 22)

 

- so if ssh with password is working, this is the moment when we can try passwordless operation (it needs a pubic/private RSA key pair and public part should be placed on remote machine's authorized_keys file, 

  but a caveat is here that on ALT-F there is no openssh but SSH is realized by dropbear instead. It is the reason that key generation was easier on windows for me as I've written it in an earlier line)

  another problem is that dropbpear has an own format for keys so we need to convert id_rsa to dropbear format this way:

 

     dropbearconvert openssh dropbear /home/nasuser/.ssh/id_rsa /home/nasuser/.ssh/id_dropbear

 after that ssh should work in passwordless mode:

  

     ssh -i /home/nasuser/.ssh/id_dropbear  nas...@192.168.1.2

- if all above is done then the last step is to start rsync:

 rsync -avh  --rsh="ssh -i /home/nasuser/.ssh/id_dropbear" nas...@192.168.1.2:/cygdrive/e/Docs /mnt/md0/arch/Docs --fuzzy --delay-updates --delete-delay   

DONE.....

 

 (--fuzzy --delay-updates --delete-delay  : I found it on web as a recommended setting combo to handle renamed files, deletions well

 at this moment it ok gor me as well)

 

----------------------------------------------------------------------------------------- 

I've created a script around this final rsync command with this functionality:

- comparing a honeypot doc file with a stored copy of it to prevent overwriting previously archived files with 

encrypted / infected files in case of ransomware/virus infection on the windows machine.

If the honeypot doc is changed, rsync is not started but a warning email is sent to me

and a warning message is put in the archived directory with a file (warning is in the file name) to warn me if I did not see the mail yet.

- every run places a file in the archived directory (on windows machine) with timestamp in its name to know when the archiving run last time.

[João Cardoso]

Some more tips:

-You can install the 'openssh' Alt-F package, and administer it under Services->Network, opensshd, Configure. By default it works on port 2222, and dropbear continue running on port 22. You can exchange that in the webUI.

-You can generate rsa/dss/ecda keys on dropbear by using 'dropbearkey'. You can convert betwwen openssh/dropbear key formats by using 'drobearconvert'

-Although not "ransomware" aware, the Alt-F backup service (Services->System, backup, Configure), does some work on the same line. It was tested only for the CIFS backup type (with SMB1), so I didn't mention it to you (I should).

It I configure it for the rsync type (see the bottom of the backup webUI online help), and you have a rsyncd or sshd server running on the target host, it should work also. If I do that and try to run the backup, /var/log/backup.log says:

DATE=Thu Apr 16 16:31:23 WEST 2020
backup: Doing backup: id=0 type=rsync runas=jcard host=mono srcpath=Users/Joao Cardoso/Documents  dstpath=/Backup when=0 at=0 log=no nlogs=0
rsync: failed to connect to mono (192.168.1.105): Connection timed out (110)
rsync error: error in socket IO (code 10) at clientserver.c(127) [Receiver=3.1.3]
NO rsync module
Generating 2048 bit rsa key, this may take a while...
Public key portion is:
ssh-rsa AAAA...
Fingerprint: sha1!! d6:9f:64:34:af:06:f9:85:1b:a1:56:ac:53:7d:15:62:13:db:98:09
backup: ID 0: ssh keys have been created for you.
You must now setup a trusted password-less connection from host DNS-320L
to host mono. This can't be automated, manual intervention is needed:
1-Logged in as user jcard at host mono you should execute the commands
       cd      # change to your home directory
       scp DNS-320L:.ssh/id_rsa.pub . # copy public key generated at DNS-320L to mono
       cat id_rsa.pub >> .ssh/authorized_keys # allow password-less connection from DNS-320L
2-Login as user jcard to host DNS-320L and execute the command
       ssh mono # this will make DNS-320L a trusted host to host mono
After accepting, you can logout.

And a file /home/Joao Cardoso/Backup-rsync-ssh.txt with instructions created.

Now that you have sshd running and rsync available, it might work? Can rsyncd be started as a service in the windows box? It would be much faster then using rsync over ssh (although not encrypted).

I would appreciate any comments.

Thanks

[Zoli]

On Thursday, April 16, 2020 at 6:00:55 PM UTC+2, João Cardoso wrote:

Some more tips:

-You can install the 'openssh' Alt-F package, and administer it under Services->Network, opensshd, Configure. By default it works on port 2222, and dropbear continue running on port 22. You can exchange that in the webUI.

Yes, it is a good point, I missed it, but now I don't need it.

 

-You can generate rsa/dss/ecda keys on dropbear by using 'dropbearkey'. You can convert betwwen openssh/dropbear key formats by using 'drobearconvert'

when I've realized that my RSA keys are not working I have found dropbearconvert. Before that I did not know that dropbear can even convert keys. But for next time ... or for others it is good to know, thanks.

 

-Although not "ransomware" aware, the Alt-F backup service (Services->System, backup, Configure), does some work on the same line. It was tested only for the CIFS backup type (with SMB1), so I didn't mention it to you (I should).

It I configure it for the rsync type (see the bottom of the backup webUI online help), and you have a rsyncd or sshd server running on the target host, it should work also. 

I did not know about it also, Probably because I did not press "create backup dir" button when I've browsed menus. I have installed ALT-F about 1 month ago only.

This backup solution seems limited to 3 hosts/folders but my family has 5 computers.

Now that you have sshd running and rsync available, it might work? Can rsyncd be started as a service in the windows box? It would be much faster then using rsync over ssh (although not encrypted).

I would appreciate any comments.

Thanks

Actually I don't know how to start rsyncd in cygwin on windows. If the solution is working that I've put together with your help then I will not change it for a while. We don't have so many and big files so speed is not the most important thing for me now.

What is important for me that somehow I have to ensure that the NAS notice in time that a host is up and start rsync. The hosts are desktops and laptops so possible that the time window is quite short on some days.

I have made an R.PI internet radio earlier where I had to check if internet is available or not before starting to download the stream. There I've checked ping response from yahoo. Probably it will work here too but with local addresses.

Thanks, Zoli

[João Cardoso]

On Friday, 17 April 2020 13:07:53 UTC+1, Zoli wrote:

On Thursday, April 16, 2020 at 6:00:55 PM UTC+2, João Cardoso wrote:

Some more tips:

-You can install the 'openssh' Alt-F package, and administer it under Services->Network, opensshd, Configure. By default it works on port 2222, and dropbear continue running on port 22. You can exchange that in the webUI.

Yes, it is a good point, I missed it, but now I don't need it.

 

-You can generate rsa/dss/ecda keys on dropbear by using 'dropbearkey'. You can convert betwwen openssh/dropbear key formats by using 'drobearconvert'

when I've realized that my RSA keys are not working I have found dropbearconvert. Before that I did not know that dropbear can even convert keys. But for next time ... or for others it is good to know, thanks.

 

-Although not "ransomware" aware, the Alt-F backup service (Services->System, backup, Configure), does some work on the same line. It was tested only for the CIFS backup type (with SMB1), so I didn't mention it to you (I should).

It I configure it for the rsync type (see the bottom of the backup webUI online help), and you have a rsyncd or sshd server running on the target host, it should work also. 

I did not know about it also, Probably because I did not press "create backup dir" button when I've browsed menus. I have installed ALT-F about 1 month ago only.

This backup solution seems limited to 3 hosts/folders but my family has 5 computers.

[added:] ah... fill in the 3 entries and after submitting three more empty entries will be available. That's the general behaviour :)

Now that you have sshd running and rsync available, it might work? Can rsyncd be started as a service in the windows box? It would be much faster then using rsync over ssh (although not encrypted).

I would appreciate any comments.

Thanks

Actually I don't know how to start rsyncd in cygwin on windows. If the solution is working that I've put together with your help then I will not change it for a while. We don't have so many and big files so speed is not the most important thing for me now.

What is important for me that somehow I have to ensure that the NAS notice in time that a host is up and start rsync. The hosts are desktops and laptops so possible that the time window is quite short on some days.

Then one more tip: the backup service, when set for a given host, retrieves its MAC, and at backup time sends it a WOL (Wake On Lan) packet using the 'ether-wake' command,

 and waits a couple of minutes to see if the host wakes up. Setting up WOL on windows uses to be done on the network properties, but I'm not sure if the WOL packet traverses the WIFI router to wake up a laptop.

An example log of a successful and unsuccessful attempt:

DATE=Sun Apr 5 06:00:01 WEST 2020
backup: Doing backup: id=0 type=NFS runas=jcard host=silver srcpath=/home/jcard dstpath=/Backup when=0 at=6 log=no nlogs=30
backup: ID 0: waking up silver
backup: ID 0: silver is awake

...

DATE=Sun Mar 29 06:00:01 WEST 2020
backup: Doing backup: id=0 type=NFS runas=jcard host=silver srcpath=/home/jcard  dstpath=/Backup when=0 at=6 log=no nlogs=30
backup: ID 0: waking up silver
backup: ID 0: still waking up silver
backup: ID 0: still waking up silver
backup: ID 0: still waking up silver
backup: ID 0: still waking up silver
backup: ID 0: still waking up silver
backup: ID 0: couldn't awake up silver
backup: ID 0: host silver not answering, exiting.