I am making changes to my file in aptana studio and save my changes. But when I do that, I am getting the following error? Why is that?
Here's the error:
Failed to save the remote file due to exception "Opening File Failed". Would you like to save the file locally instead?
Will appreciate your help.
Yes, it is a file permissions issue.
Make sure your remote server has right permissions.
chown -R YOURUSER:YOURGROUP .
It's confused because you can open to read it, but then it fails to save with the annoying dialog to save it locally.
Related
Use the newest code to compiled.
When running the worldserver ,it has a error and shutdown.
Here is the error in the log .
Updating World database...
Duplicate filename "E:/AzerotherCore/data/sql/archive/db_world/6.x/2022_01_22_00.sql" occurred. Because updates are ordered by their filenames, every name needs to be unique!
Could not update the World database, see log for details.
If I rename the sql file, the massage comes below
Updating Auth database...
It seems like the update "2022_01_23_03.sql" '6291006' was renamed, but the old file is still there! Treating it as a new file! (It is probably an unmodified copy of the file "2022_01_23_00.sql")
Then I check the file with same name in "data\sql\updates" and "data\sql\archive", I found their code is the same ,too.
So, my question is :could I delete the sql files in "data\sql\archive" ，and then run the server without any potential issues?
It sounds to me that your config option Updates.ArchivedRedundancy has been enabled, if you disable it the worldserver will stop searching the Archived files.
After upgrading to macOS Catalina with latest Xcode 11, I am not able to read files directly from user path when doing unit testing, example:
PROJECT_DIR + "/FolderX/myFile.json",
I keep getting error Thread 1: EXC_BAD_ACCESS (code=1, address=0x8)
This is also happened when I am trying to open a couchbase lite database with custom path.
Error:
error opening!: 14
Cannot open database, Error : Error Domain=SQLite Code=14 "unable to open database file" UserInfo={NSLocalizedDescription=unable to open database file}
I believe this is an issue due to the read write access between my simulator and the latest Catalina.
My current workaround is to add my files and database to target membership and read the files directly from [NSBundle bundleForClass:[self class]].bundlePath.
Is there any better fix to this? Like tweaking any setting to allow it to read files from custom path like in older versions?
You might try looking in SystemPreferences > Security&Privacy > Privacy tab. From there, scroll down to "Files and Folders" <-- There's where you can see programs and the folders they have been granted access to in Catalina.
Personally, I didn't have time to waste figuring out how the new file permissions are supposed to work, so I let Xcode have full disk permission. (Right above the "files and folders" is "Full Disk Access".
Of course, that solved all my issues... after I get a chance to play with the new file permissions, I may revoke that access and give it explicit folder access.
Well if anyone is still struggling with this, I've moved all my projects outside of ~/Documents/
it is strange that projects under ~/Documents/ doesnt get asked for read permission, other paths do!
I end up putting all my projects under ~/workspace/
** for those who doesnt know, ~/ means /Users/{your username}/
Check your File Access settings in the App Sandbox in your project's settings, under Signing and Capabilities. For example, I couldn't access files in /Users/Bert/Downloads, even after turning on Full Disk Access in Security and Privacy in System Preferences. I had to grant read access to the Downloads Folder in App Sandbox settings.
My script ran successfully in Unix but not in a command task of an Informatica workflow. The permissions are fine, and the parameter file and variables have been declared in the workflow. Why is this happening?
Make sure that the machine you are running informatica on, is running in a unix box.
If it is on a windows machine, you will have to run the DOS equivalent command for your script.
Check whether informatica repository is pointing to same UNIX server, in which the script to executed from informatica is present.
I to faced same situation ,please check the propertied of script file make it as 755(CHMOD),It should work.
Regards
Rama
This could be a permission issue. If you are executing a shell command from Informatica, right click the file in SFTP and click on "Properties" (I am using Winscp).Give full permission to the file and now it should work.
I have a small Perl-based CGI application, which I am running in the project web space provided for a SourceForge project. This application stores data in a SQLite (v. 3) database file.
When I run test scripts from a shell, I can read from and write to this SQLite file. However, when the CGI code is executed by Apache, it has read-only access. Write operations result in a log file error:
error.log.web-2:[Wed Oct 27 14:40:22 2010] [error] [client 127.0.0.1] DBD::SQLite::db do failed: unable to open database file
For testing purposes, I have cranked the permissions for that SQLite file all the way up to 777. No difference.
However, there are some funny caveats to SourceForge's project web space, and I wonder if I'm being tripped up by that. Generally, the main web server filesystem is read-only to Apache. If you have files that need to be writable at runtime, you're supposed to store them in a special "persistent" directory elsewhere... and create symlinks from your web space to the actual files under that directory.
I have done this, and the permissions are set to 777 for both the symlink and the actual SQLite file under the "persistence" location. I know this mechanism works in general, because I'm doing the same thing with cache and log files and it works there.
I'm wondering if there's anything funky about SQLite itself, along the lines of it not wanting to open a symlink (rather than a raw file) for writing.
I believe the answer to this question is that it can't be done. Further research into SQLite tells me that the driver must get a lock on the database file before it can do any write operations. This type of lock cannot be obtained when the actual file is on a different machine with its filesystem cross-mounted.
I believe this is the case with SourceForge project web space hosting. It looks like the (writable) "persistent" directory is actually on a totally separate machine from the read-only web server filesystem.
In short, if you stumble across this question because you're having the same issue... either look for different web space hosting, or else it may be time to re-work your app and step up to MySQL or some other DB (SourceForge gives you free MySQL hosting anyway).
Another issue is if you have permissions for the specific db file but you don't have permission to make the temporary files in the directory. (Mixed permissions, or too restrictive permissions)
https://www.sqlite.org/tempfiles.html
If you can't write the temporary files then you can't do any writes on a sqlite database file. If you switch it to a :memory: database you could get by or maybe use the pragma mentioned by #bob.faist PRAGMA temp_store = MEMORY, but really you should diagnosis and fix the permissions problem if possible.
Use these commands to see if you have permission to write in those file locations.
ls -l app.db
getfacl app.db
ls -l -d . # check the directory to see if you can write the temp files there
getfacl .
Use chmod or setfacl -m to fix the files or folders to let you write to them.
Also check your diskspace.
df -k
If it shows that your partition where the database file is located or is trying to write its files to are full, you could also get these kinds of issues.
Hope that helps.
I have a SQLite database that I am using for a website. The problem is that when I try to INSERT INTO it, I get a PDOException
SQLSTATE[HY000]: General error: 8 attempt to write a readonly database
I SSH'd into the server and checked permissions, and the database has the permissions
-rw-rw-r--
I'm not that familiar with *nix permissions, but I'm pretty sure this means
Not a directory
Owner has read/write permissions (that's me, according to ls -l)
Group has read/write permissions
Everyone else only has read permissions
I also looked everywhere I knew to using the sqlite3 program, and found nothing relevant.
Because I didn't know with what permissions PDO is trying to open the database, I did
chmod o+w supplies.db
Now, I get another PDOException:
SQLSTATE[HY000]: General error: 14 unable to open database file
But it ONLY occurs when I try to execute an INSERT query after the database is open.
Any ideas on what is going on?
The problem, as it turns out, is that the PDO SQLite driver requires that if you are going to do a write operation (INSERT,UPDATE,DELETE,DROP, etc), then the folder the database resides in must have write permissions, as well as the actual database file.
I found this information in a comment at the very bottom of the PDO SQLite driver manual page.
This can happen when the owner of the SQLite file itself is not the same as the user running the script. Similar errors can occur if the entire directory path (meaning each directory along the way) can't be written to.
Who owns the SQLite file? You?
Who is the script running as? Apache or Nobody?
For me the issue was SELinux enforcement rather than permissions. The "read only database" error went away once I disabled enforcement, following the suggestion made by Steve V. in a comment on the accepted answer.
echo 0 >/selinux/enforce
Upon running this command, everything worked as intended (CentOS 6.3).
The specific issue I had encountered was during setup of Graphite. I had triple-checked that the apache user owned and could write to both my graphite.db and its parent directory. But until I "fixed" SELinux, all I got was a stack trace to the effect of: DatabaseError: attempt to write a readonly database
This can be caused by SELinux. If you don't want to disable SELinux completely, you need to set the db directory fcontext to httpd_sys_rw_content_t.
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/railsapp/db(/.*)?"
restorecon -v /var/www/railsapp/db
I got this error when I tried to write to a database on an Android system.
Apparently sqlite3 not only needs write permissions to the database file and the containing directory (as #austin-hyde already said in his answer) but also the environment variable TMPDIR has to point to a (possibly writable) directory.
On my Android system I set it to TMPDIR="/data/local/tmp" and now my script runs as expected :)
Edit:
If you can't set environment variables you can use one of the other methods listed here: https://www.sqlite.org/tempfiles.html#temporary_file_storage_locations
like PRAGMA temp_store_directory = 'directory-name';
In summary, I've fixed the problem by putting the database file (* .db) in a subfolder.
The subfolder and the database file within it must be a member of the
www-data group.
In the www-data group, you must have the right to write to the
subfolder and the database file.
####### Additional Notes For Similar Problem #####
I gave write permissions to my sqlite database file to other users and groups but it still didn't work.
File is in my web root directory for my .NET Core WebApi.
It looked like this:
-rw-rw-rw- 1 root root 24576 Jan 28 16:03 librestore.db
Even if I ran the service as root, I kept getting the error :
Error: SQLite Error 8: 'attempt to write a readonly database'.
I also did a chown to www-data on the librestore.db and I still received the same error.
Finally I moved up above my webroot directory and gave others write access to that directory (LibreStore - the root of my WebApi) also and then it worked.
I'm not sure why I had to give the directory write access if the specific file already had write access, but this is the only thing that worked.
But once I made that change www-data user could access the .db file and inserts succeeded.
I got the same error from IIS under windows 7. To fix this error i had to add full control permissions to IUSR account for sqlite database file. You don't need to change permissions if you use sqlite under webmatrix instead of IIS.
I used:
echo exec('whoami');
to find out who is running the script (say username), and then gave the user permissions to the entire application directory, like:
sudo chown -R :username /var/www/html/myapp
(For followers looking for an answer to a similar question)
I'm building a C# .Net Core 6.0 WPF app. I put the Sqlite.db3 on the c:\ drive for convenience while developing. To write to the database I must open Visual Studio 2019 as Administrator.
#Charles in a comment pointed out the solution to this (or at least, a botch solution). This is merely me spelling it out more clearly. Put file_put_contents('./nameofyourdb.sqlite', null); (or .db, whichever you fancy) in a .php file in the root directory of your app (or wherever you want the db to be created), then load that page which renders the php code. Now you have an sqlite db created by whichever user runs your php code, meaning your php code can write to it. Just don't forget to use sudo when interacting with this db in the console.
A good clean solution to this is to allow the file of your main user account to be written to by (in my case) the http user but this worked for me and its simple.
None of these solutions worked for me and I suppose I had a very rare case that can still happen. Had a power shortage so even with 777 permissions on folder and db file, without SELinux, I would get this error.
Turns out there was a jellyfin.pid file (not sure if it's named after the service or user as they have the same name) locking it after the power shortage. Deleted it, restarted the service and everything worked.
I got this in my browser when I changed from using http://localhost to http://145.900.50.20 (where 145.900.50.20 is my local IP address) and then changed back to localhost -- it was necessary to stay with the IP address once I had changed to that once