buzzra

Members
  • Posts

    40
  • Joined

  • Last visited

Posts posted by buzzra

  1. On 6/12/2020 at 3:52 PM, buzzra said:

    Hello,

    I just installed from Unraid Community Applications. No changes made to config. I go to http://myserver.mydomain.com:8438 and the Pinry homepage comes up. And that's it. I can't register, I can't login, and I don't know how to pin anything. Where do I go from here? I thought I read all the docs, but there is nothing about admin except editing the local_settings.py file, but no explanation of how to edit or why.

    Thanks

    buzz

    Nevermind. Deleted it. doesn't work and no support.

  2. Hello,

    I just installed from Unraid Community Applications. No changes made to config. I go to http://myserver.mydomain.com:8438 and the Pinry homepage comes up. And that's it. I can't register, I can't login, and I don't know how to pin anything. Where do I go from here? I thought I read all the docs, but there is nothing about admin except editing the local_settings.py file, but no explanation of how to edit or why.

    Thanks

    buzz

  3. 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. 🙄

  4. @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. 

     

     

  5. 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.  

  6. 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

     

  7. 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?

     

  8. 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 

  9. 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

  10. 41 minutes ago, Djoss said:

    Not sure what is the root cause of the issue.  There is probably a setting somewhere in unRAID that cause this.

    What is the filesystem of your disks?

    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

  11. On 2/6/2019 at 9:28 PM, Djoss said:

    I guess that accessing 

     

    Can you try to add the same parameter, but to the call of "mysql_install_db" in /etc/cont-init.d/nginx-proxy-manager.sh?

    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

  12. On 2/7/2019 at 1:47 PM, jonathanm said:

    Remember that a docker is a sort of mini virtual machine, much of the updates are to keep the base OS inside the container up to date.

    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

  13. 5 hours ago, Djoss said:

    Could you try the following:

    • Start the container.
    • Login to the container: docker exec -ti NginxProxyManager sh
    • Edit the file located at /etc/services.d/mysqld/run: vi /etc/services.d/mysqld/run
    • Add the parameter "--innodb-flush-method=fsync" next to "/usr/bin/mysqld".
    • Save and exit.
    • Stop the container.
    • Remove the appdata folder.
    • Start the container.

    I followed the instructions above. Still not working.

    After removing the appdata folder and restarting the container, it comes up for a few seconds, creates the appdata folder and everything beneath it, and then stops. The init_db.log file is created with the same error. If I restart the container, it comes up and stays up, but I still can't get to the webui. I verified the changes to the 'run' file were still there. 

    Here are the contents of current 'run' file and init_db.log:

    #!/usr/bin/with-contenv sh
    
    set -e # Exit immediately if a command exits with a non-zero status.
    set -u # Treat unset variables as an error.
    
    mkdir -p /run/mysqld
    chown $USER_ID:$GROUP_ID /run/mysqld
    
    echo "[$(basename "$(pwd)")] starting..."
    exec s6-applyuidgid -u $USER_ID -g $GROUP_ID -G ${SUP_GROUP_IDS:-$GROUP_ID} /usr/bin/mysqld --innodb-flush-method=fsync --datadir /config/mysql --tmpdir /tmp/
    
    # vim:ft=sh:ts=4:sw=4:et:sts=4
    Installing MariaDB/MySQL system tables in '/config/mysql' ...
    2019-02-06 11:05:28 22602701859720 [ERROR] InnoDB: preallocating 12582912 bytes for file ./ibdata1 failed with error 95
    2019-02-06 11:05:28 22602701859720 [ERROR] InnoDB: Could not set the file size of './ibdata1'. Probably out of disk space
    2019-02-06 11:05:28 22602701859720 [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-06 11:05:28 22602701859720 [ERROR] Plugin 'InnoDB' init function returned error.
    2019-02-06 11:05:28 22602701859720 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
    2019-02-06 11:05:28 22602701859720 [ERROR] Unknown/unsupported storage engine: InnoDB
    2019-02-06 11:05:28 22602701859720 [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

    Thanks for your time and help!

     

    buzz

  14. 14 hours ago, Djoss said:

    So you have "Tunable (enable DirectIO)" set to Auto and it's not working?

    Can you try to temporarily set the config directory to something like "/tmp/NginxProxyManager" to see if it works?

    Yep, works when set to /tmp/NginxProxyManager. Will not work set to any user share on the array or the cache drive. Any ideas why? I have other Dockers running fine using the appdata share on the cache drive. I also have VMs running on another cache drive only share.

     

    Thanks for the help

    buzz

  15. 8 hours ago, Djoss said:

    Do you have any error in the container's log?

    Also, the first time your start the container it may take longer for the UI to be ready (db needs to be created).

    There are no errors in the Nginx logs, but this is the init_db.log:

    Installing MariaDB/MySQL system tables in '/config/mysql' ...
    2019-02-01  2:06:01 22916083571592 [ERROR] InnoDB: preallocating 12582912 bytes for file ./ibdata1 failed with error 95
    2019-02-01  2:06:01 22916083571592 [ERROR] InnoDB: Could not set the file size of './ibdata1'. Probably out of disk space
    2019-02-01  2:06:01 22916083571592 [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-01  2:06:01 22916083571592 [ERROR] Plugin 'InnoDB' init function returned error.
    2019-02-01  2:06:01 22916083571592 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
    2019-02-01  2:06:01 22916083571592 [ERROR] Unknown/unsupported storage engine: InnoDB
    2019-02-01  2:06:01 22916083571592 [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

    It's definitely not a disk space problem as there is 369 GB available. 

    edit: Sorry, after looking at my log file and going back through this topic, I see others have had this problem. My Settings -> Global Share Settings -> Tunable (enable DirectIO) is set to Auto. I have never changed it. My appdata share is normal as far as I know. I have a few other dockers running fine. It is on the cache drive, /mnt/user/appdata with 'use cache disk:' set to only.

     

     

     

  16. I'm having a strange problem with this docker. I finally got the time to install it, and everything seemed to go fine. I left all the settings default, since there were no conflicts with other dockers or VMs my Unraid host.

    The problem is that I can't get to the webui. I try to connect to 'myunraidip:7818'  and I get "This site can’t be reached x.x.x.x refused to connect." I can connect to :1880 and get the Nginx congratulations page. 

    I did an Nmap scan of my host from another machine and I see all the ports I expect open, except 7818. Any ideas?

     

    buzz

     

      

  17. 11 hours ago, Squid said:

    They're both correct.  Depends upon what you want.  jc21 is the author of the app itself and maintains the github for the app.  DJoss is the author of the container (which includes the app) and maintains it.

     

    Because 99% of the time, any bug is with the app itself, and not with the container.

     

    It's kinda akin to getting food poisoning from eating cereal.  Is the cereal itself bad (the app), or is it the box (djoss' container) that then transferred something to the cereal?

    Thanks for the explanation. Makes complete sense. And thanks Djoss for packaging this up in an Unraid container. I hope no one was offended by my questions. I just saw both and had not seen an explanation of the relationship. 

    I will be installing this and moving my other containers to it. It looks to be VERY easy to manage. I have been using a sort of 'automatic' reverse proxy named nginx-proxy (https://hub.docker.com/r/jwilder/nginx-proxy/~/dockerfile/) but it took a lot to get it working in Unraid. 

     

    Thanks again to everyone supporting this project.

     

    buzz