I've been attempting to figure out this problem for quite some time and have looked at all the normal solutions. I am attempting to run a .backup on an sqlite database. I don't think it matters, but this particular database is being used by Membase and is also running on the Amazon cloud. Both the folder that I am backing up to, and the folder that the database is coming from has 777 permissions (which is the normal cause of this message). If I sudo the backup command, it gets partway through the backup and then the process just hangs while consuming CPU usage and leads me to eventually kill the sqlite process. I even went through and chmod 777 the database file itself.
Here is whats happening:
/opt/membase/bin/sqlite3 /mnt/data-store/default-data/default-0.mb '.backup /mnt/data-backup/mbfiles/test.mb'
Error: unable to open database file
When I ls -la the folder:
drwxrwxrwx 2 membase membase 4096 Sep 10 15:41 .
drwxrwxrwx 4 membase root 4096 Aug 5 01:10 ..
-rw-r--r-- 1 membase membase 53248 Sep 10 15:41 default
-rwxrwxrwx 1 membase membase 849593344 Sep 10 15:41 default-0.mb
And the backup folder:
drwxrwxrwx 2 ec2-user ec2-user 4096 Sep 10 15:41 .
drwxrwxrwx 4 root root 4096 Sep 3 00:26 ..
Also, because I hear it matters, the permission of /tmp
drwxrwxrwt 3 root root 4096 Sep 10 03:32 .
I've been trying to fix this for over a week now, and any new ideas would be appreciated. It should be noted that this is a production environment so restarting is not an option.
EDIT: I checked and I can back up the smaller "default" file, just not the larger db, so this rules out any sort of issue with folder permissions. Any help would be hugely appreciated.
Thanks!
This seems like an sqlite issue. We've seen sporadic occurrences of this error at other customers but have not been able to track it down or resolve it yet. According to the sqlite experts, this should never happen ;-)
Can you shutdown the Membase process to test further? If so, trying to take a backup (make sure the 'memcached' process is stopped) at this point would rule out any issue with software accessing the file. If it still doesn't work at this point, I know there are tools to verify a sqlite DB (just don't have them off the top of my head).
You can also use a combo of ".dump" and ".restore" via sqlite, but I wouldn't recommend running that on a running Membase node as we haven't tested out the effects.
Perry
Related
I have a Synology Diskstation DS216se running DSM 6.2.3-25426. I've installed MariaDB 10, Web Station, PHP 7.2, and myPhpAdmin, but when I open it at http://diskstation/phpMyAdmin/ I get this error message
"Sorry, the page you are looking for is not found."
I'm using an nginx server in Web Station, and the error log at /var/log/nginx/error.log contains multiple entries like the following
*621 open() "/var/services/web/phpMyAdmin/js/vendor/jquery/jquery.debounce-1.0.5.js" failed (13: Permission denied)
The file, and all other files with permission denied entries in the logs, exist in the /var/services/web/phpMyAdmin/ directory - what permissions need to be granted to the directory for this to succeed?
I hit this as well. I managed to recover, but it effectively amounts to hard clearing any evidence of prior installs of Web Station, PHP 7.2, phpMyAdmin, and any other web related services. Then manually ripping out some bad directories with broken symlinks/permissions.
My hypothesis is that I tried to install adminer prior to this and - having not done any set up for Web Station et. al. - it put the filesystem in a bad state.
I am not willing to try installing adminer again to test this hypothesis.
What I did to fix this:
Backup what you need (e.g., any personal web site).
SSH into your diskstation. Please be aware of what you are doing and keep in mind the big picture. Don't go deleting random things.
Uninstall Web Station, PHP 7.2, Apache, phpMyAdmin, etc. Anything that Web Station would ultimately be inclined to read and serve up.
Verify that /var/services/web doesn't contain anything you care about, and delete it (sudo rm -rf /var/services/web).
Verify that /volume1/web doesn't contain anything you care about, and delete everything inside it (sudo rm -rf /var/services/web). You may need to chmod permissions for this - I ended up leaving the web directory itself intact, but nothing inside.
Reboot. Mount any encrypted disks, etc.
Check that /var/services/web now shows it is symlinked to /volume1/web, e.g. sudo readlink -e /var/services/web.
Also check permissions for /volume1/web, e.g. ls -al /volume1. It should be owned by root:root and have permissive (777) bits.
Install Web Station, PHP 7.2, and phpMyAdmin in that order.
After this, I could open phpMyAdmin and be served its log in screen.
Debugging notes:
For me, when I SSH in I see in the logs similar issues:
2020/12/17 10:36:35 [error] 32658#32658: *1028 "/var/services/web/phpMyAdmin/index.php" is forbidden (13: Permission denied),
ps says that the nginx workers run as the http user (uid=1023(http) gid=1023(http) groups=1023(http)).
The directory /var/services/web/ appears to be owned by root, both group and user:
# ls -al /var/services/web/
total 424
drwxr-xr-x 3 root root 4096 Dec 17 10:29 .
drwxr-xr-x 3 root root 4096 Dec 17 10:22 ..
-rw-r--r-- 1 root root 27959 Apr 13 2016 adminer.css
-rw-r--r-- 1 root root 82 Apr 13 2016 .htaccess
-rw-r--r-- 1 root root 387223 Apr 13 2016 index.php
drwxr-xr-x 10 root root 4096 Dec 17 10:29 phpMyAdmin
It's not clear to me how Web Station's nginx is intended to work at all given the mismatch - perhaps some set of actions I took prior caused it to decide to install with bad ownership.
I decided to leave everything owned by root, but changed group permissions so that http can access:
# chown -R root:http /var/services/web/
# chmod -R 775 /var/services/web/
This got past the initial error, but revealed a new one:
"/usr/syno/synoman/phpMyAdmin/index.cgi" is not found (2: No such file or directory)
Indeed, there was no trace of phpMyAdmin anywhere in that directory. Evidence of a bad install.
I decided to uninstall anything web related: phpMyAdmin, PHP 7, Apache (happened to be installed), nginx, and Web Station. Once I did, I still had two files in /var/services/web: adminer.css index.php.
I had tried adminer prior to this. In /var/services, there were symlinks to specific volume locations, e.g.:
# ls -al /var/services/
total 12
drwxr-xr-x 3 root root 4096 Dec 17 10:22 .
drwxr-xr-x 17 root root 4096 Dec 17 10:21 ..
lrwxrwxrwx 1 root root 18 Jan 20 2020 download -> /volume1/#download
lrwxrwxrwx+ 1 root root 14 Dec 17 10:22 homes -> /volume1/homes
lrwxrwxrwx 1 root root 24 Jan 20 2020 pgsql -> /volume1/#database/pgsql
lrwxrwxrwx 1 root root 13 Dec 17 10:22 tmp -> /volume1/#tmp
lrwxrwxrwx 1 root root 13 Dec 17 10:22 web
Interestingly, web was not symlinked. I fully deleted /var/services/web.
Looking over at /volume1, I do see a /volume1/web, again fully owned by root but with extremely constrained permission:
d---------+ 1 root root 52 Dec 17 10:14 web
There are only a few things in here, which look related to a blank install of Web Station. I fully deleted everything within /volume1/web, but left it as is. With everything maximally cleaned I rebooted.
Upon boot, /var/services/web was now symlinked to /volume1/web, which now also had useful permission bits (777), and owned by root:root. Maybe this was done by some boot recover process, who knows. (I still have nothing web related installed at this point.)
I installed Web Station, then PHP 7.2, then phpMyAdmin.
I had the same issue when accessing my server via
<name>.local/phpMyAdmin/
It worked when I accessed it via
<local ip>/phpMyAdmin/
I am running a Wordpress Install (OpenLiteSpeed) in a Google Cloud Compute VM running Ubuntu
I can access the main folder of Wordpress via web browser by typing in the static IP - but I cannot access individual files and/or folders on my machine via web browser.
I would like to share files by posting links to files located in on the VM, Wordpress install folder.
How can I do that?
My permissions of the folder inside the worpress install are:
thisisme#wordpress-vm:~$ ls -la /var/www/html/myFolder
total 432
drwxrwxrwx 2 thisisalsome thisisalsome 4096 Mar 21 09:39 .
drwxr-xr-x 6 thisisalsome users 4096 Mar 21 09:59 ..
-rwxrwxrwx 1 thisisalsome thisisalsome 433790 Mar 21 09:02 pic.jpg
You need to move the /var/www/myFolder folder into the /var/www/html folder and access files by hostname/myFolder/myFile.zip or to configure the webserver to serve your myFolder under a different dns.
That is probably because your default webserver's configuration only serves files from the /var/www/html folder.
#Octavian
I did use the same capitalisation - but i just realised I made the mistake of using the wrong access path - i was typing
xx.xx.xxx.xxx/html/myFolder/pic.jpg
but I should have used
xx.xx.xxx.xxx/myFolder/pic.jpg
AND NOW IT WORKS !! Thanks for pointing that out for me! I did not know UNIX servers are case sensitive!! :) Thanks For Your Help!
I'm running airflow 1.10.3, on Red Hat Linux. I'm using a LocalExecutor, and the webserver and scheduler are both started via systemd.
The log files being generated by the scheduler are world-readable (i.e. mode "-rw-rw-rw-"). The log directories being created are "drwxrwxrwx".
This fails the security scans my organisation has in place. I need to be able to restrict the permissions on these files.
The umask in /etc/profile is 077. I've also added UMask=0007 to both the systemd unit files for the services. However, although this seems to be working for the logs in the dags/logs/scheduler/ directory, it is not affecting the DAG run logs.
[root#server logs]# ls -la s3_dag_test/
total 4
drwxrwxrwx. 4 airflow airflow 54 Aug 7 17:35 .
drwxrwx---. 46 airflow airflow 4096 Aug 7 20:00 ..
drwxrwxrwx. 5 airflow airflow 126 Aug 7 17:37 bash_test
drwxrwxrwx. 5 airflow airflow 126 Aug 7 17:29 check_s3_for_file_in_s3
[root#server logs]# ls -la s3_dag_test/bash_test/2019-08-07T17\:29\:27.988953+00\:00/
total 12
drwxrwxrwx. 2 airflow airflow 19 Aug 7 17:35 .
drwxrwxrwx. 5 airflow airflow 126 Aug 7 17:37 ..
-rw-rw-rw-. 1 airflow airflow 8241 Aug 7 17:35 1.log
This is probably too late to be a helpful answer for you, but I had the exact same issue. My organization raised the permissions of the Airflow log directories as a security finding. I likewise checked the umask, to no avail.
I did manage to find this:
https://anoopkm.wordpress.com/2020/03/26/world-readable-airflow-dag-logs-issue/
In a nutshell, it looks like Airflow hard-codes the permissions used for creating files and folders.
I edited this Python file: venv/lib/python3.8/site-packages/airflow/utils/log/file_task_handler.py and changed lines 242 and 247 to use the 0o770 and 0o660 instead of 0o777 and 0o666 for creating folders and files, respectively. Then I manually triggered a DAG and checked the folder permissions. The newest log folder no longer had global rwx permissions.
Can you let us know how airflow is installed as normal user or root user
I was trying to start Phabricator's Notification Server, but experienced the following error:
/phabricator/phabricator/bin/aphlict start
[2015-11-16 18:41:08] EXCEPTION: (FilesystemException) Requested path '/var/tmp/aphlict/pid' is not writable. at [<phutil>/src/filesystem/Filesystem.php:1081]
arcanist(head=master, ref.master=9dd6eafb5254), phabricator(head=master, ref.master=50d158a8c4d9), phutil(head=master, ref.master=e9ed72483a14)
#0 Filesystem::assertWritable(string) called at [<phutil>/src/filesystem/Filesystem.php:73]
#1 Filesystem::assertWritableFile(string) called at [<phutil>/src/filesystem/Filesystem.php:89]
#2 Filesystem::writeFile(string, string) called at [<phabricator>/src/applications/aphlict/management/PhabricatorAphlictManagementWorkflow.php:140]
#3 PhabricatorAphlictManagementWorkflow::willLaunch() called at [<phabricator>/src/applications/aphlict/management/PhabricatorAphlictManagementWorkflow.php:249]
#4 PhabricatorAphlictManagementWorkflow::executeStartCommand() called at [<phabricator>/src/applications/aphlict/management/PhabricatorAphlictManagementStartWorkflow.php:15]
#5 PhabricatorAphlictManagementStartWorkflow::execute(PhutilArgumentParser) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:406]
#6 PhutilArgumentParser::parseWorkflowsFull(array) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:301]
#7 PhutilArgumentParser::parseWorkflows(array) called at [<phabricator>/support/aphlict/server/aphlict_launcher.php:23]
The directory in question seems to be writable:
ls -l /var/tmp/aphlict
total 4
drwxr-xr-x 2 root root 4096 Nov 16 13:40 pid
If it matters, I'm running all operations as non-'root' on Ubuntu 14.04 LTS system.
I have just figured out this. As I said in the recent update, I was trying to start notification server as non-'root'. Looking again at permissions of the /var/tmp/aphlict/pid folder, the problem suddenly became crystal clear and trivial.
ls -l /var/tmp/aphlict
total 4
drwxr-xr-x 2 root root 4096 Nov 16 13:40 pid
Therefore, all that needed to be done to fix the problem is to make the directory writable for everyone (I hope that this approach does not create a potential security issue):
chmod go+w /var/tmp/aphlict/pid
su MY_NON_ROOT_USER_NAME -c './bin/aphlict start'
Aphlict Server started.
Problem solved. By the way, for the Notification Server to work properly, do I need to open port 22281, in addition to already opened 22280? (Please answer in comments. Thank you!)
phpmyadmin has been installed and working fine for months, installed via this repo:
deb http://ppa.launchpad.net/tuxpoldo/phpmyadmin/ubuntu utopic main
Suddenly, I couldn't login; no in-page errors but the logs showed:
PHP message: phpmyadmin: Failed to load /etc/phpmyadmin/config-db.php Check group www-data has read access and open_basedir restrictions"
PHP message: phpmyadmin: Failed to load /var/lib/phpmyadmin/config.inc.php Check group www-data has read access and open_basedir restrictions"
So, I checked:
ll /etc/phpmyadmin
drwxrwxr-x 3 www-data www-data 4096 Nov 16 20:11 ./
drwxr-xr-x 132 root root 12288 Nov 17 15:33 ../
-rw-r----- 1 www-data www-data 549 Nov 16 20:11 config-db.php
and
ll /var/lib/phpmyadmin
drwxr-xr-x 4 www-data www-data 4096 Oct 8 15:51 ./
drwxr-xr-x 62 root root 4096 Nov 12 13:10 ../
-rw-r----- 1 www-data www-data 4478 Nov 16 19:48 config.inc.php
I followed this SO answer and changed the user and group permissions to match the example (user:root, group:www-data) and changed the directory permissions to match.
I double, triple checked that no open-basedir restrictions are in effect, and I checked phpinfo()
I tried changing the permissions to be that of the fpm worker pool.
I rebooted.
I did an sudo apt-get install --reinstall phpmyadmin.
The ONLY thing I've done inbetween is to follow this guide to installing freePBX, and 90% of what it wanted was on my machine anyway; only things like sqlite were installed, and I can't even be sure it was that which stopped it working. Long shot, but perhaps worth mentioning.
Everything else, all other sites etc, are running fine. Before I lose any more hair than I have done in the last 5 hours, I'd really appreciate some ideas. Thanks!
Turns out this is a rather misleading message from phpmyadmin:
Check group www-data has read access and open_basedir restrictions.
But anyone running multiple sites, using php-fpm and concerned at all about security will have separate pools for each site.
The solution, in my particular case was:
chown -R phpma:phpma /var/lib/phpmyadmin
chown -R phpma:phpma /etc/phpmyadmin
chown -R phpma:phpma /usr/share/phpmyadmin
Then sudo dpkg-reconfigure -plow phpmyadmin
Incidentally, it appears that doing a package install on Ubuntu splatters files all over the place, and it goes a little something like this:
/etc/phpmyadmin/config.inc.php
includes the following files in this order, which really won't need touching unless you want to up the login cookie validity.
/var/lib/phpmyadmin/blowfish_secret.inc.php // self explanatory
/var/lib/phpmyadmin/config.inc.php // LoginCookieValidity etc
/etc/phpmyadmin/config-db.php // Leave this one alone
/usr/share/phpmyadmin/config.inc.php // auth, host, connection etc
I hope this helps someone else at any rate.
This is certainly due to the fact you are using mpm_itk_module.
If yes, you have to use in your apache settings :
<ifmodule mpm_itk_module>
AssignUserId myuser www-data
</ifmodule>
instead:
<ifmodule mpm_itk_module>
AssignUserId myuser myuser
</ifmodule>
phpmyadmin need group www-data, and if you use AssignUserId, with another group it fails off course.
And you can add to you apache config in "Directory":
php_admin_value open_basedir "/home/yourpath/htmldir:/etc/phpmyadmin:/var/lib/phpmyadmin"
Replace /home/yourpath/htmldir by your own web dir.
I hope this help