Hello. I’m a new user. I installed and started testing and using Rockstor about a week ago.
I’ve been able to set it up and everything works as I expect it to, but I can’t figure out how to rsync from a Linux or Mac TO the Rockstor.
I can ssh to the Rockstor using the root or one of the user accounts. I can also mount an sftp share from either Linux or Mac.
When I run the rsync command, it seems to run and shows all of the files in the terminal, but none of the files are actually transferred.
The command I used is:
rsync -av ~/folder user1@rockstorip:/path
where folder is the folder on my local machine which I want to sync to the Rockstor.
and rockstorip is the rockstor’s ip; /path is the path on the rockstor. I’ve tried different paths, including shares which user1 is set as the owner, but I can’t get the transfer to work.
I’ve used the same rsync syntax with another Linux box and it works fine, but I can’t get it to work with the Rockstor. I think it may be that I"m not setting the rockstor’s destination path correctly or choosing a folder which it can’t write to.
So I got a little further this time. It works if I use the root account.
Obviously, I don’t want to use the root account. Can someone who understand the rockstor’s underlying permission relationships between accounts and the file system give me a hand?
When you create a share, you can assign the owner and group of the share.
It sounds your shares are probably owned by the root user and group.
To alleviate this, you should assign your shares to another user. System -> Shares -> [sharename] -> Access Control -> Edit, change Owner and Group to something more appropriate.
For example, I created the user ‘media’ on my system, assigned it to the group ‘users’, and setup my shares with that user and group.
Thanks for the hint. Are you able to use the user account you created ‘media’ to run an rsync against the Rockstor server shares which are owned by ‘media’?
And did you need to change anything else to be able to rsync?
"By default no user other than root are allowed to login via ssh or use SFTP. This restriction improves security but means there are certain conditions that must be met to gain sftp access to a Rockstor share.
The SFTP user must be a Rockstor user
The SFTP user must also be the owner of an exported SFTP share
These restrictions make Rockstor’s SFTP implimentation more suited for individual storage needs as opposed to a shared storage area accessed by multiple users. In the following example we will setup a secure share for use by a single user, ie for secure file access / storage across client platforms."
The doc also shows a share export accessed from Linux (nautilus), OS X (Cyberduck), and has some windows links.
However there is your:
so probably not just a share ownership issue. Take a look at the doc anyway and see if it helps, ie maybe you are missing the Add SFTP Export step. Or there may be an issue with the chroot mechanism.
the sftp connection works fine, but the rsync still does not. (I tested the sftp connection with Cyberduck from my Mac)
The instructions document says the sftp folder is supposed to be created as /mnt3// however, when I ssh as root and run a df -h, it is not. It is created under /mnt2 (without ).
When I created the user, I tried making it a member of the Users group & also leaving the default of Group - create a new one. Based on the instructions, I think it’s supposed to be it’s own group, with the same name as the user.
When assigning the access control for the smtp share, I set the owner to the new user; for the group, I first set it to the matching new user group & then also to the Users group (as per @Haioken’s suggestion). Still didn’t work with either setting.
If you have any other suggestions, I’d appreciate it.
It’s possible I’m doing something wrong and just not seeing it although it seems pretty straight forward.
If you don’t have any other suggestions, I’ll start fresh this weekend and try it again.
Just another piece of information - when I try to create the user as a member of the Users group, I get an error:
Traceback (most recent call last):
File “/opt/rockstor/src/rockstor/rest_framework_custom/generic_view.py”, line 41, in _handle_exception
yield
File “/opt/rockstor/src/rockstor/storageadmin/views/user.py”, line 167, in post
suser.save()
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/base.py”, line 685, in save
“unsaved related object ‘%s’.” % field.name
ValueError: save() prohibited to prevent data loss due to unsaved related object ‘group’.
and that referenced pr was merged and released around the beginning of August 2017 in the following Rockstor version 3.9.1-4 mid August 2017:
So it looks like you may be running a rather old version all in. Plus the even older 4.10 kernel.
Your options to get this fix and very many other fixes are to subscribe to either update channel and apply the then pending fixes, or to specifically hand edit the relevant file: it’s a one line addition fix that addresses your reported user add issue. If you follow the “specifically the following commit:” link above it will indicate the additional line required and where to put it.
Also note that if you opt for the stable channel release, which additionally helps to sustain Rockstor’s development (and is actively maintained), you should take a look at the following forum thread which addresses a known initial bump in that upgrade path:
Thanks for the report; but always best to subscribe to either update channel first prior to any bug reports, although the testing channel is now no longer being maintained due to planned changes but you should still be able to get a large number of fixes from that subscription for the time being.
The above advise is based on you running nothing older that 3.9.1-0 however.
Hope that helps.
As an aside, it may well be that your issue re sftp is related to this user issue as if the user was created but not then known to Rockstor as ‘managed’, the subsequent mechanism re the chroot mapping of the share for export may have failed. Not sure though and doesn’t explain failure re default group selection. Anyway best update and see how you go. You may have to userdel via cli and then re-create as from the commit notes the user was created anyway which might have confused things.
Hello @phillxnet. Thanks for the detailed response. I subscribed to the Testing Updates channel and upgraded to 3.9.1.16 and the kernel to 4.12.4-1.el7.elrepo.x86_64. Once I have a working configuration I plan to subscribe to the Stable Updates channel.
I went through all of the steps again after the upgrade and for some reason, I still can’t get the rsync to work. I’m not sure what I’m doing wrong and just can’t figure it out.
When I issue the command with the -n (dry run) option, it works. But when I issue the same command without the -n (rsync -av --stats /Users/xx/folder-to-sync/ test@rockstorFQDN:/mnt2/test-share/),
keep getting the same error:
Mac:Desktop username$ rsync -av --stats ~/CrossCloud/ test@rockstorFQDN:/mnt2/test-share/
test@rockstorFQDN’s password:
sending incremental file list
rsync: mkdir “/mnt2/test-share” failed: No such file or directory (2)
rsync error: error in file IO (code 11) at main.c(587) [Receiver=3.0.9]
rsync: connection unexpectedly closed (150 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.3]
If you can help me decode the problem, I will appreciate it, but if you can’t I understand. I know remote troubleshooting without being at the keyboard is difficult.
@Haioken, are you able to ssh into rockout.home with the haioken account and run all of the standard *nix commands, like ls… if yes, what does echo $PATH return?
(when I login with the test user, after upgrading and following all of the instructions, I can’t run ls, and my echo $PATH returns - /usr/local/bin:/usr/bin and I can’t cd /home/test (which is the user’s home directory and the owner and group are set correctly to test)).
For some reason, the *nix environment variables aren’t being set up correctly.
I think that is the problem and why rsync doesn’t work with a non-root user.
As before, I can still rsync successfully with the root account.
Not sure where to go from here and wondering if I should try to reinstall.
