Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About buzzra

  • Rank
    Advanced Member


  • Gender

Recent Profile Visitors

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

  1. This definitely needs to happen. It has been promised for over 3 years. Or, at least, the Doc needs to be changed to reflect that we still only have NFSv3 and NFSv4 cannot be enabled. I tried to edit the wiki, but I don't have permissions. buzz
  2. That's wierd. I get connection failed in both Chrome and Firefox with HTTPS. Something strange about my setup I'll have to figure out. Thanks buzz
  3. So, it only works via HTTP, but the link on the Unbalance settings page goes to HTTPS and you get an error. buzz
  4. Yep, parity was good. So a precautionary step you could take would be to copy just the emulated disk's data somewhere else before you replace it, in case something like this happens during rebuild. Probably not necessary most of the time, but it is something you could do if you wanted to be extra sure not to lose data. I'll have to remember that, but I probably wouldn't have done it this time anyway. 🙄
  5. @jonathanm That's probably what I'm gonna do. It was all media files. I can get them again. I still need to sync a library and see what went away. Thinking about this, If a drive goes away and is being emulated, can I still copy the data from just that drive? Was there an emulated diks4 share? I have never looked to see if that was true when I've had one being emulated.
  6. Thanks @itimpi! it works great, but knowing the file type is not helping much. I guess I could rename with the correct type and then open and see what each is. But that would take YEARS with the thousands of files in the lost+found folder that have no identification. So still pretty much lost. It is very frustrating knowing that the total used space on that drive is almost exactly what the original was, but it is 97% in the lost+found with no identification of any kind.
  7. Well, I started the array after the reiserfsck --rebuild-tree completed. The array is up and shows healthy. BUT... There are a CRAPLOAD of files in the lost +found folder. A lot have names and are in folders but most are just files with numbers for names. Pretty much no way to figure out what they were. So in essence most of the data on that drive was lost. Most likely it is because I replaced a bad drive with a bad drive, but there were no errors with the drive in it's previous life. I have replaced drives before in Unraid with used drives I had, but never had this problem. I wish there was some notification during the rebuild that the disk couldn't be written to or something. Thanks for all the help @Squid buzz
  8. Running it now. Should I deal with any files in the lost+found folder before or after I start the array with maintenance mode unchecked?
  9. Well that didn't take as long as I expected. Ended saying I need to run with the --rebuild tree option. Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs. Bad nodes were found, Semantic pass skipped 24 found corruptions can be fixed only when running with --rebuild-tree ########### reiserfsck finished at Sun Oct 6 16:27:48 2019 ########### Any recommendations before I run it?
  10. Thanks Squid. Running the reiserfsck --check now. The replacement disk was not new, but had not had any known errors in it's previous life. It only had a blank partition on it. Was I just lucky enough to use a bad drive to replace a bad drive? That would be par for the course 🙄. Also, do you think I've lost any data at this point if the drive gets repaired? I don't see it being emulated. I have some new larger drives and am planning to upgrade parity then use the new disks to upgrade to XFS. Just need to get one of those 'round tuits' 😉 buzz
  11. Hello everyone, I found disk 4 in my array had failed and was being emulated. I stopped the array and powered it off. I replaced the failed disk with another one of the same size. I powered on the array, chose the new disk as a replacement for the bad drive, and started the array. I noticed the unmountable error, but ignored it because the array was rebuilding. After the rebuild the array is up, parity shows valid and last check completed with no errors. The problem is that drive 4 still shows "Unmountable: No file system", and I still have the option to format the unmountable disk 4. All drives, including 4, show green. I haven't done anything else. I don't know what was on the bad disk, so I can't tell yet if anything has been lost. Have I lost that data? How should I proceed? From reading other forum posts, I think the next step would be to put the array in maintenance mode and do a filesystem check, but I wanted to come here and verify first. The disks are formatted with reiserfs. I have attached diagnostics. The array has not been rebooted since the rebuild. Thanks for any help, buzz la_drone-diagnostics-20191006-1644.zip
  12. Funny you should ask. I was researching this too since my last post. My filesystem is ReiserFS, since I have had my Unraid up for quite a few years. I was thinking this may be the problem, because the only things I see about it online are problems with Windows NTFS and Mac HFS. I can move my cache drive to XFS, but that's not going to be any time soon. Does anyone else have this container running on a ReiserFS system? Any other suggestions are welcome. Thanks again for all your time on this. buzz
  13. Still no good. cannot get to the webui. Still the same errors creating the database. init_db.log: Installing MariaDB/MySQL system tables in '/config/mysql' ... 2019-02-09 12:42:35 23429459561352 [ERROR] InnoDB: preallocating 12582912 bytes for file ./ibdata1 failed with error 95 2019-02-09 12:42:35 23429459561352 [ERROR] InnoDB: Could not set the file size of './ibdata1'. Probably out of disk space 2019-02-09 12:42:35 23429459561352 [ERROR] InnoDB: Database creation was aborted with error Generic error. You may need to delete the ibdata1 file before trying to start up again. 2019-02-09 12:42:36 23429459561352 [ERROR] Plugin 'InnoDB' init function returned error. 2019-02-09 12:42:36 23429459561352 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2019-02-09 12:42:36 23429459561352 [ERROR] Unknown/unsupported storage engine: InnoDB 2019-02-09 12:42:36 23429459561352 [ERROR] Aborting Installation of system tables failed! Examine the logs in /config/mysql for more information. The problem could be conflicting information in an external my.cnf files. You can ignore these by doing: shell> /usr/bin/mysql_install_db --defaults-file=~/.my.cnf You can also try to start the mysqld daemon with: shell> /usr/bin/mysqld --skip-grant-tables --general-log & and use the command line tool /usr/bin/mysql to connect to the mysql database and look at the grant tables: shell> /usr/bin/mysql -u root mysql mysql> show tables; Try 'mysqld --help' if you have problems with paths. Using --general-log gives you a log in /config/mysql that may be helpful. The latest information about mysql_install_db is available at https://mariadb.com/kb/en/installing-system-tables-mysql_install_db You can find the latest source at https://downloads.mariadb.org and the maria-discuss email list at https://launchpad.net/~maria-discuss Please check all of the above before submitting a bug report at http://mariadb.org/jira Sorry for the trouble. Thanks for the help buzz
  14. I understand that, but you didn't answer the question. I would still like to see a change log of what was updated. Does such a thing exist, and if not, why? buzz
  15. Is there anyway to see what changes are in each of these docker updates? I have done all of them, and the version number on the server management dashboard has not changed since v4.0.1.0. buzz