Frank1940

And look for a BIOS update. (I have a couple of mini/micro computers computers-- running Windows -- and I can tell you customer support is practically non-existent!)

Describe this server in some detail. If it is being based on one of the Mini/Micro computers without SATA ports, it may not be the best choice.

If you are talking about a monitor and keyboard connected directly to the server, you can not scroll backup the output of the boot sequence. However, the last two lines in the normal boot sequence) have the IV4 and IV6 addresses. One more thing, the DHCP address assignment is done by your router and normally uses the MAC address of the NIC to track things. Once it assigns an IP address to a NIC, it will assign that same IP address to that NIC until its lease expires. For most home routers, the lease time is a few days at the shortest. (As I understand, the lease time-out period starts when the NIC is disconnected-- think powerdown -- from the router. So usually, a computer could have the same IP address forever on most home routers.)

These items worry me. They look like they are files that should have been deleted when the boot drive was created. I assume that you created this boot drive yesterday (April 21). Let me ping @JorgeB and see if he has some thoughts. Have you purchase a license linked to the GUID of this flash drive?

While are using the terminal (SSH or console), check the results of this command line: ls -al /boot The reason for this request are these lines in the syslog: Apr 21 14:36:50 Tower kernel: md: could not read superblock from /boot/config/super.dat Apr 21 14:36:50 Tower kernel: md: initializing superblock Apr 21 14:36:50 Tower emhttpd: Unregistered Flash device error (ENOFLASH4) Something is going on with the boot drive... You might want to check to see that it is plugged into a USB2 socket rather than a USB3 socket. (USB3 and the boot drive are occasionally not compatible...)

Try using the address in your browser: http://192.168.50.34

Upload that diagnostics in a NEW post in this thread. Shut the server down. remove the Unraid Flash Drive and you will find the diagnostic ZIP file in the /logs folder/directory. You can shut the server down cleanly by (1) type the following command on terminal powerdown or (2) push the server power switch for about one second.

I took a look at your diagnostics and the syslogs consisted of ~25,000 lines of the same error message! I would recommend that you reboot the server and grab ethe diagnostics as soon as it comes up. Then check to see if /mnt/user is present as a directory. Post the diagnostics file and your observation. If it is there, watch and see if it 'disappears' again and get the diagnostics file asap.

I have read some discussions about using this switch. Just realize what it will do if you decide to use it. If you 'accidentally' (or anything else happens--Hacker, careless user, malware. etc.) delete a file from the source, this switch will delete it from the destination file system. This will make it difficult (or, possibly, impossible) to recover those files. IF you just leave them there on the destination file system, they will be there if you ever need to find them again. The only reason for using the -delete switch is to make sure that both the source and destinations file system are mirrors of each other. If your objective to be able to recover 'missing' files, it may turn out to be counterproductive in some respects! If you are backing up temporary file systems and there is a need to delete them periodically, I would only use that switch on that segment of the file system that those files are in. (I store the complete command line for each of the rsync commands that I use a plain text file and copy-and paste the appropriate command line into GUI terminal window.)

You are well beyond me on using rsync. I did enough research at the time to develop a command line that would work for my simple case. I ran modified versions of it to break up in the job into manageable chucks. (I was moving 19TB of data in that initial move!) Since then I run it manually when I deem necessary. Of course, it only moves those files that are new (or changed) since that initial backup. It does provide a listing of those files in the terminal. I do look at that output to verify that it is doing what I expect, I am not concerned about logging its actions. (rsync is a well tested utility and I don't expect that I would uncover some great hidden bug!) Here is my command line: rsync -avhPX /mnt/remotes/192.168.1.245_Media/All\ Movies/ /mnt/user/BackupMedia/All\ Movies/ And I have attached a file that I put together when I was building the switches that I used. Hope this helps... Rsync--ComonlyUsedSwitches.txt

Not sure about SyncMate as I have never used it. (I have used rsnyc for a few months to keep my Media files in sync and I can tell you it is trouble free. But I only use it to update the back server from the main server with all new files and any file updates done on the Main Server.) That was why I asked where you were running SyncMate from. If it was from the Unraid there should be a support link where you should be able to get your answers. Quick note on rsync. It is a freeware distribution that has been ported for virtually all UNIX/Linux distributions. It is a command line utility in its basic form. It is included as a part of the Unraid installation package. I understand that there are Windows and MacOS ports. It is required that the computers on both ends of the connection have rsync installed.

What are you using to do this transfer. SMB or NFS. With SMB, root is not a valid SMB user on Unraid ! Where is SyncMate running? You have listed the error messages in the above post. Is this how they appear when you see them? (If there is more than one 'paragraph' to each of these error messages, it would be helpful if they appear as you are seeing them.) Try using the code (The </> icon ) message formatting option.

The connection is 'broken' is always broken when the client is shutdown. As I understand, the client and the server do a handshake operation the first time that the client tries to connect to the server. (Note that this first contact could be setting up a 'mapped' Windows drive...) Be sure that you read that post from LimeTech back on 2013 about the login handshaking that goes on. SMB has its roots back in Windows for Workgroups which was introduced back in the early 1990's. At that time, SMB was intended to link together a few computers in small engineering groups who wanted to share data without restrictions among their group. (My first experience using it was with 10 base 2 cards and RG-58 cabling.) It has evolved over the last thirty years into the basic standard networking protocol for the Governments and businesses. And this has resulted in it becoming a prime target for every hacker in the world. So security is now the watchword for SMB. The goal of SMB is now to ensure that only verified authorized users ever gain access to a SMB server. If you as a user don't qualify in even the smallest detail, SMB is going to deny you access.

That PC is only allowed one login/connection to any Server. (That restriction is enforced by the client PC.) That means if that client PC establishes a login to your Unraid server silently, any attempt to login with another set of login credentials will fail! Here is an old post that describes what happens behind the sceans: https://forums.unraid.net/topic/25064-user-share-problem?tab=comments#comment-228392 No. I should be a one time deal to add them and Windows should continue to use them forever. Note that every user on that client has their own environment...

Windows will allow only one connection from a Windows client computer to any server. (As I understand it,this is strictly a Windows policy!) There was a backdoor where you could use the IP-Address of a server and the server's Network name to set up two connections. BUT I have not been able to get that to work for some time. Windows also has recently implemented a policy that guest/anonymous connections to servers are not allowed. Window networking error messages are confusing and often misleading. Many folks try to get around Windows security policies and sometimes, they are successful. But, essentially, they are just hacking Windows security and MS may plug these hacks at any time in the future. I feel that it best to just set things up the way MS wants them to be. Here is a link to a couple of PDF files that will help you do this: https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/