WannaTheater

I removed the user-script plugin, and both scripts, and the discs mounted successfully. I am running a parity check (will take all night).

Thank you for your help. Everything WAS working great. Now after my last reboot, I cannot start the array. The GUI gets hung up on "Mounting Disks." When I telnet to machine, all disks seem to be mounted correctly, and all user shares are set up. But the array will not start, and the web interface becomes non-responsive. Attached is the last log file if you have any advice- Unison is pretty cool. It allows me to sync certain directories on my Office PC to my unraid server. The unraid server only requires a small executable running in background for the connection to my Office PC. The Office PC has all the configuration files (which directories to sync, files to ignore, etc), and is run on demand. syslog.txt

OK- For the most part this now works. But this created a new issue- I cannot stop the array. It gets hung up unmounting shares. In order to fix the issue, I need to telnet to the unraid server, and manually kill the Unison process running in the background. Perhaps I also need a StopUnison.sh script that determines the process it, and kills it, to be scheduled on Array Stop. Now to research the syntax...

After reading up and installing the user script, I am thinking this may work: 1) Create a directory on flash drive config/plugins/user.scripts/scripts/StartUnison 2) Create a file in that directory called StartUnison.sh with the following contents: #!/bin/bash #Set UNISON environment variable export UNISON=/mnt/disk4/appdata/unison #Start Unison process in background (assuming I create a /mnt/disk4/bin directory and copy the Unison executable to it) /mnt/disk4/bin/unison -socket 1111 & 2) When configuring the script in the Unraid web interface, schedule script to run at STARTUP of array. The assumption here is that it runs just after all the discs are mounted, so it will find the Unison executable. I am unsure if I should run the StartUnison.sh in background or foreground. (Linux is not good, but I am assuming that when the StartUnison.sh completes, it will not kill the actual unison prcess that is running in background with "&') Does that seem correct? Thank You!

Thanks for the feedback- it helps. For clarification, I am trying to accomplish the following, at the time my unraid server boots up: 1) Set an environment variable named UNISON to /mnt/disk4/appdata/unison. From itimpi, it doesn't appear that I can do this in the "go" file, as the array has not started (directory location not available). 2) Start the executable named Unison and run in background, with a specific socket number. I currently have the Unison executable file located the unraid flash drive (7M). It is currently being started through the "go" file with the following command: # Start Unison/boot/unison -socket 1111 & The issue I am having is once "/boot/unison -socket 1111 &" is kicked off, if there is no UNISON environment variable set, Unison defaults to looking for its files in "$home/.unison." If that directory is not there, it will create it. I need it to point to a constant location, as it accesses files there, writes logs, etc. So on every Unraid reboot, this directory gets recreated with nothing in it. ken-ji- It looks like you were mentioning something about a login script, but then mention a user script. Got me confused. Can this somehow be done WITHOUT me logging on? I am looking to have it done at startup, like an "autoexec.bat" from the old days I would even prefer to get the "Unison" executable off the flash drive, and put into a location on the array (perhaps even /mnt/disk4/appdata/unison)

Anyone? I am a bit hesitant to "trial and error" this- Thanks

In my quest for a replication solution, I am still trying to get Unison working on unraid. (I have been unable to find a docker image, let alone have any idea how to get it up and running). I have modified \\tower\flash\config\go to include the startup command: (the Unison executable is on my boot drive). # Start Unison /boot/unison -socket 1111 & Unison does start and work properly for the most part. It places some sync files *someplace*, but these are deleted after an unraid reboot, causing syncing to start from scratch (hours), vs. incrementally. From the manual: The .unison Directory Unison stores a variety of information in a private directory on each host. If the environment variable UNISON is defined, then its value will be used as the name of this directory. If UNISON is not defined, then the name of the directory depends on which operating system you are using. In Unix, the default is to use $HOME/.unison. In Windows, if the environment variable USERPROFILE is defined, then the directory will be $USERPROFILE\.unison; otherwise if HOME is defined, it will be $HOME\.unison; otherwise, it will be c:\.unison. I believe $HOME is /root on unraid. I have created a directory where I would like my unison sync files to be stored, and remain after an Unraid shutdown: \\tower\disk4\appdata\.unison Questions: 1) Is "\\tower\flash\config\go" run after disks are mounted? 2) If so, can I modify the "go" file to set the environment variable like this: UNISON=/mnt/disk4/appdata/.unison -or- set UNISON=/mnt/disk4/appdata/.unison (My linux is not good!) 3) Any risk to what I am trying to do? (i.e. does having an executable write directly to a /mnt/disk4 directory compromise the integrity of unraid file system?) (I normally just use window shares for copy/paste, never programatically modify data on my unraid server) Thanks for any help you can offer.

Great information. I will check it out when I get some time. But for now, Unison appears to be working. It is not running in a docker container- Just as a process that starts up at boot time. In a prior version of Unraid, I needed to manually kill the unison process on the unraid server as it was hanging up the shutdown process. That doesn't appear to be an issue anymore.

Thank you for the recommendation. I will look a little deeper. Seems like it requires me to build another server. I continue to use Unison, as it has been my go-to for years keeping multiple PCs in sync, with primary data on a local PC. (unRaid is used for movie storage, which I do not consider to be all that critical). I would like to migrate ALL data over to UNRAID, and keep it refreshed on a weekly basis through UNISON (as I do with my other PCs).

It has been awhile, so I thought I would revisit this- Are there any Unraid/Docker gurus that are willing to tackle this? Thanks

So I am revisiting this. Some time ago I managed to get Unison working (syncing from PC to Unraid), but there was an issue- Basically I could not shut down unraid unless I telneted over to unraid and manually killed the Unison process. This to me is not really a good solution. So I started investigating how to install Unison in a docker container. In combination with the LimeTech Docker "user guide", I tried this: https://github.com/vikduf/docker-unison, since I could find the template repository it was under (https://github.com/vikduf/docker-templates) But when creating the container, I received an error stating it was out of date. So I found this: https://github.com/leighmcculloch/docker-unison Unfortunately, I can't find it in a template repository, which deviates from the LimeTech Docker "user guide." Not knowing any details about Docker, I am lost as how to proceed, and don't want to mess up unraid array. Once installed, I know how to use unison... I just can't figure out how to get it installed. Anyone willing to tackle this, or provide some pointers? Thanks!

I thought I had this working but: 1) Unraid will not unmount the drives unless I manually kill unison process on Unraid

Scratch that- It looks like I am having issues. I would love to see a supported working configuration.

I was able to get Unison running, but did not use a docker container. I followed this thread: It seems to work fine. I did have an issue unmounting drives last week, which appeared to go away after I killed the Unison process running on unRaid, but still have to determine if that is the actual cause of the issue.

Thanks- So bottom line is to leave this new drive as XFS. And convert the old drives to XFS as some point in time. That being said, as long as a failed drive can successfully be rebuilt in unRaid while using mixed file systems, than I will probably just leave things for now- Thanks Again.