Delarius

It's definitely somewhere on that /boot drive, just a matter of figuring out how to search for it. Not sure using the old servername is the right approach. The cronjob will no doubt look something like this: 5 4 * * 0 /root/backup.sh So in this instance I'd try using "backup.sh" as my keyword.

It's coming from your /boot volume (the flash drive) - probably easiest to determine a keyword in your cronjob - something somewhat unique if possible. Then you can do something like this to figure out where that root cron is coming from: $ grep -r "mykeyword" /boot/ That should give you a list of the possible matches and hopefully it's easy to determine where the root cron is coming from.

This won't help you now, but having been a Linux admin for many years - If you ever think the command you are typing might be destructive or could be if you accidentally hit Enter at the wrong time: Type echo before that command, like this: $ echo rm -rf /mnt/blah/blah Then if you make a mistake, it'll just return your command on the command line, and won't do anything. When you are happy that you haven't made a terrible error, you can always press up arrow, then Control-a and remove the echo part. I find it particularly useful when doing batch jobs where a mistake might really ruin your day. A fake and not great example is: $ for i in $(ls myfolder); do rm -rf $i; done If you put an echo in there, it'll just display what it's going to do before you actually do it which can be a lifesaver: $ for i in $(ls myfolder); do echo rm -rf $i; done Just a tip because humans make mistakes all too often and just adding echo can really help prevent serious oopsies.

Also looks like you aren't getting an IP address. That's the most likely cause of this issue. I would try plugging in an ethernet cable to all of the ports on your server and see what it finds. Currently it looks like it's not selecting the expected ethernet port. The HPE servers can definitely be a little finicky in regards to their network ports so test all of them because you should be getting a dhcp address from your router, not the 169.x.x.x address.

Fair enough, I don't think it would be that difficult. An example script would be something like this and you can just switch the mounts/mount points (even using an echo loop if you like): mkdir -p /mnt/mytransferdir mount.cifs -o username=mysynologyuser,password=mysynologypasswd,file_mode=0660,dir_mode=0770,vers=2.1 //SynologynameorIP/sharename /mnt/mytransferdir rsync -avz /mnt/mytransferdir/ /mnt/user/Pictures #or whatever you need umount /mnt/mytransferdir # Repeat this with each share you want syncd Could easily work with an NFS share if that's how you roll and Synology will let you mount on the command line. The thing is that if you can just get one good rsync, then subsequent rsyncs won't presumably need to copy all the data, so even if you can get this to work once, your initial plan might be slow but adequate.

I don't own a Synology, but is there a reason why you couldn't mount the Synology share in unRaid and then just use a local cron job to rsync directly? I would presume you should be able to mount the Synology share, do an rsync and then umount the share.

Hi! I think this is the issue. Normally when I do this I don't put a passphrase on the key. It's not the password of the server, it's a special passphrase to make your key more secure. If you want automation, redo your key generation and press enter when you get prompted for a passphrase. You can also test with the verbose flags -v through -vvv in your ssh command to give you a little more feedback about what is failing. Try something like: # ssh -vvv [email protected] That should sort this out. Del

@henris Thanks for that post. Got me thinking about it and the last step - reboot the server? I absolutely recommend rebooting your server instead of doing this but... If you really can't reboot now and are willing to accept some possible weirdness (because we aren't going to install this quite like the script wants): 1. login to your server via bash shell 2. # cd / 3. # tar xf /boot/config/plugins/dynamix.system.stats/dynamix.system.stats.txz commands are after the # and don't blame me if you do this wrong - if/when you do - reboot.

That's works too. I just figure if for whatever reason /root/.bash_profile doesn't exist then the cat command will create it, and if it does exist - then the cat command (via >>) will append to it. Thus I don't use a test since there's no condition where the cat command isn't useful.

I'm not sure if this is the answer you need, but I do this all the time. Make a file with the contents you want at /boot/config/mybashprofile (or whatever name you want but that's the general location.) Then in your go file at /boot/config/go - add a new line that reads: cat /boot/config/mybashprofile >> /root/.bash_profile Reboot to test.

I might be missing something, but I just don't see the great utility in plugging into 'unRaid drives' directly. If you want to do this, you could certainly just manually assign a reasonable IP address to both the Mac and unRAID and use a network cable between the two to 'directly plug into' your server then mount via SMB/NFS - whatever you prefer. Given expected speeds of spinning disks there's little benefit to plugging in via usb directly. If for some strange reason this is absolutely needed, you'd need to start with FUSE on your Mac (which is a whole other can of worms and suffers from some performance hits anyways.) However, the posts above are correct - unless you're prepared for a complete rebuild of parity (and have excellent backups) don't do this. Use the native abilities of unRAID to your advantage.

You can definitely do this, Any commands you want to run after a reboot can be put in /boot/config/go The server will run the go script at startup. There's obviously another few ways to achieve - like the CA User Scripts idea above. You can modify the routing table directly via commands such as: ip route add 192.168.0.0/16 via 192.168.1.111 I'm not at my machine right now but I believe you can also use files with the name route-eth# to define routes for an interface - should be placed at /etc/sysconfig/network-scripts/ So you could make a file called route-eth0 - put your desired routes in it - save to /boot/config/route-eth0 and in your go file just copy the file into place. However, you'd need to check if this worked after a reboot because the network might need cycling afterwards. The commands route or ip r might help too.

I don't know if unRAID is the solution for this. I think if I was required to make something work, it would be in using a few techniques - all of which would have to be run from on boot from the 'go' file and then setup cron jobs. I won't get into details as I haven't experimented with this, but I think it could be possible (although very kludgy and apt to break on updates.) First I'd put some items into the /boot/config/go file: - define the group(s) and memberships - so issue some form of the groupadd command (need to create users before this.) - define the base permissions - essentially I'd remove all access from a shares for all users - add the access permissions back using as many iterations as necessary - setfacl -m g:groupname:rwx /mnt/disk1/myshare/mydirectory (or similar - unRAID does support ACLs) - be sure to also set the default acls - so something like setfacl -m d:g:groupname:rwx /mnt/disk1/myshare/mydirectory - add something to the root crontab at /var/spool/root/cron to check the permissions on a regular basis - you might also need to modify your smb.conf - I'd probably modify it live - restart samba and test - then copy that file to /boot/config/mysmb.conf and copy it over with the go script, then restart samba It think it would be possible to do what you want, but somewhat challenging and I think because of how unRaid shares work there might be many pitfalls with this approach. However, I think using standard POSIX permission/ownership it might be tricky to make this happen - mostly because the shares seem to always use the nobody user and that could be a problem. I have noted that acls do work as expected. However - do remember if you use acls, you need to be very careful about your use of chmod. Specifically adjusting the group permissions with chmod will also adjust the 'mask' and restrict the acls you've already applied, which is somewhat non intuitive. Another solution would be to run a Linux VM with access to a share(s) and have that VM share out the filespace and apply it's own permissions. Regardless, I think if you wanted a challenge, you've got one. Good luck, Del

I am connected successfully. I do have a few questions though. I've figured out how to add new users - didn't see this documented anywhere obvious so for others: echo -ne "newusername:" >> /mnt/user/appdata/binhex-rtorrentvpn/nginx/security/auth sh -c "openssl passwd -apr1" >> /mnt/user/appdata/binhex-rtorrentvpn/nginx/security/auth This should prompt for a password and add it to the auth file - allowing newusername to login to nginx - bear in mind your path may differ. My question is about some logged warnings, perhaps they are worth reconciling? 1. Mon Aug 7 07:56:05 2017 WARNING: file 'credentials.conf' is group or others accessible - This appears to be correctable by: chmod 700 /mnt/user/appdata/binhex-rtorrentvpn/openvpn/credentials.conf but this doesn't quite work because this file is written at startup. 2. WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1542' - Does this matter? Typically I'd expect to see the same MTU number on both - any reason this can't be set to the same? Otherwise, apart from what appears to be a quirk about retaining settings, this is working great. Thank you for a great docker.

Hi, I'm really struggling to get this rtorrentvpn docker to work. Here's what I've tried: 1. installed normally - set to pia and included username password - there's no obvious entry required for port VPN_PORT on the config page so left that alone. - Launched - get this error: 2017-08-05 13:12:29.378329 [crit] Missing OpenVPN configuration file in /config/openvpn/ (no files with an ovpn extension exist), please create and then restart this container, exiting... 2. Used wget to add the desired ovpn (us-seattle.ovpn) file directly to /mnt/user/appdata/binhex-rtorrentvpn/openvpn/ 3. Checked permissions - seem fine nobody:users owner. 4. Relaunch - now i get this error: 2017-08-05 13:18:36.295839 [info] VPN config file (ovpn extension) is located at /config/openvpn/us-seattle.ovpndos2unix: converting file /config/openvpn/us-seattle.ovpn to Unix format...2017-08-05 13:18:36.354217 [info] VPN remote line defined as 'us-seattle.privateinternetaccess.com 1198 udp'2017-08-05 13:18:36.409652 [info] VPN_REMOTE defined as 'us-seattle.privateinternetaccess.com'2017-08-05 13:18:36.465773 [crit] VPN_PORT not found in /config/openvpn/us-seattle.ovpn, exiting... 5. Removed the .ovpn file and instead using 'add variable' in unraid docker editing - manually added variables for VPN_PORT, VPN_REMOTE, VPN_PROTOCOL using ones found in the ovpn file - now getting: 2017-08-05 13:25:28.115021 [crit] Missing OpenVPN configuration file in /config/openvpn/ (no files with an ovpn extension exist), please create and then restart this container, exiting... 6. Turned off VPN in docker settings - relaunch - works fine. 7. Turn on VPN and keep getting the two types of errors shown above - either [crit] VPN_PORT not found in /config/openvpn/us-seattle.ovpn if the file is present OR [crit] Missing OpenVPN configuration file in /config/openvpn/ (no files with an ovpn extension exist), please create and then restart this container, exiting... when the file is not present 8. tried removing the manually set variables, deleting container and starting anew - same results. 9. also tried adding line reading port 1198 to the us-seattle.opvn file I have really searched through the forum and totally can't find anything specifically related to this. Any tips would be appreciated. ---- UPDATE SOLVED ---- Corrected this by editing the us-seattle.opvn file. It needs to look like this: client dev tun proto udp remote us-seattle.privateinternetaccess.com 1198 resolv-retry infinite nobind persist-key setenv CLIENT_CERT 0 [...] used to look like this: client dev tun remote us-seattle.privateinternetaccess.com 1198 udp resolv-retry infinite nobind persist-key setenv CLIENT_CERT 0 This has corrected the issue. Not sure why the pia files were written differently, but this issue is now corrected. Launch and log .rtf