buzzra
-
Posts
40 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by buzzra
-
-
What's the difference between RustDeskServer and RustDeskServer-Relay? I know there is an hbbs and hbbr parts to RustDesk, is that the difference here?So we need both of these dockers installed at the same time?
-buzz
- 1
-
On 3/6/2022 at 6:25 AM, Squid said:
Not quite sure.
Try this
rm -rf /tmp/community.applications rm /boot/config/plugins/community.applications/community.applications.cfg
And reload the apps tab
Also had the same problem. The above commands fixed it.
-
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.
-
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
-
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
- 1
-
-
So, it only works via HTTP, but the link on the Unbalance settings page goes to HTTPS and you get an error.
buzz
-
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. 🙄
-
@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.
-
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.
-
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
-
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?
-
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?
-
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
-
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
-
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
-
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
-
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
-
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
-
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 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
-
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.
-
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
-
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
[Support] FoxxMD - pinry
in Docker Containers
Posted
Is this project still alive? Doesn't seem to be many recent updates. Are there any good alternatives?