Frank1940

Members
  • Posts

    9861
  • Joined

  • Last visited

  • Days Won

    17

Frank1940 last won the day on March 24

Frank1940 had the most liked content!

6 Followers

Converted

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Frank1940's Achievements

Veteran

Veteran (13/14)

961

Reputation

94

Community Answers

  1. Connect up a monitor and Keyboard to your Unraid server. Login as 'root' using your standard login credentials. Then type the following on the command line: diagnostics Look at where it has stored the file on your Unraid boot drive. You can push the power switch on the server for about two seconds and it should shutdown the server down cleanly. Pull the flash drive and upload that diagnostics file as an attachment in a NEW post in this thread.
  2. Post your Diagnostics file (the entire .zip file) in a NEW post in this thread. It will provide much more information about what is going on. Next, take a deep breath. I am going to provide a link to the Unraid manual. I would suggest that you take a couple of hours and peruse it. https://docs.unraid.net/category/manual/ One more thing, Unraid needs healthy disks to be able to provide data protection. Windows could care less less about disk health until it tries to use the actual area of a disk that has problems. All Hard Disks will eventually fail! How much of a headache such a failure will cause depends on the configuration of the storage. Unraid provides protection against either one or two disks failures depending on whether you have one or two parity drives. It also allows you to 'test' the array for problems on a periodical basis using the Parity Checks operation. Again, let me caution you! There are a lot more ways to lose data than a simple hard disk failure. As an example, your Unraid server could end up in the cloud with a little help from a tornado! 🙄 You need a minimum of two separate copies of every file. Preferably with one of them being off-site!
  3. In this case, you use your problem solving skills and try to figure out what type of file they might be. Once you have an idea, you try to open them with programs that can normally read them. If you are lucky, you might be able to salvage them. If you can't figure it out, Just delete the files and lost+found folder and thank your lucky stars that two files were all you lost.
  4. Remember that @JorgeB said this: That stick is bad and should never be used again in any computer!!!! The second stick may still be defective but that would almost totally defy the odds!
  5. Please understand that Unraid by itself is not a backup. It can be a part of a backup but not as a single copy of valuable/irreplaceable data. See here for a discussion: https://forums.unraid.net/topic/130726-unraid-os-version-6113-available/page/5/#comment-1206692
  6. You have found the exact reason that a cache drive was added to Unraid in the first place. There is no way around this slow-writing problem when writing directly to the array. (I did a quick calculation and you are getting a 1TB of data every 3 hours...) You can speed things up a bit by enabling "Turbo-Write". See here: https://forums.unraid.net/topic/50397-turbo-write/ I recall reading the other day, that there many be some additional relief for delays caused by FUSE when we get to Linux kernel 6.20 but there will still be the physical limitations imposed by head movements and rotation delays of hard drives.
  7. 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!)
  8. 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.
  9. 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.)
  10. 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?
  11. 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...)
  12. Try using the address in your browser: http://192.168.50.34
  13. 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.
  14. 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.
  15. 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.)