A user with permission to create folders and components is not able to copy and paste items through WebDAV. This User is using Mac OS X Lion. The error he gets is that he does not have read and write permissions. Is there any resolution?
The WebDAV Connector is enabled by default server-side per the SDLLiveContent documentation at least for SDL Tridion 2011.
Only valid items are allowed via WebDAV which includes binaries (multimedia in Tridion), .xml components, and other types.
It seems like the user doesn't have permissions to read and write for a given folder. You can confirm by having them attempt creating folders or components in the same folder in the Content Manager Explorer (CME).
Is it possible that the Mac does not authenticate properly to Windows. In this case, you should be able to see the failed connections in your server logs. Is this user (or any other Mac user) able to use webdav successfully in any other folders?
As it's been suggested already, you will have to do some detective work to determine what exactly is failing. Tridion permissions do not change based on the client you use, so if they work from one client, they must work from another (excluding authentication issues here).
Go to your Windows Event Viewer, Tridion Content Manager log, check for error messages written to it when you try to copy content from the mac.
Post the exact error message you're getting. I doubt that Tridion is telling you "user is don't have read and write access"
Bottom line, if it works from Windows and not Mac, the issue is not with the WebDav server, but with the WebDav Client.
I also fail to see the programming question on this one...
What version of Tridion are you using? First action which you should do is to check Event Log for error messages (it was already suggested by Peter Kjaer), if you don't have anything there you can try to enable webdav debug logging by modifying cc_crtd_def.xml file which is situated in Tridion\webdav\WebDAVcartridges\Default\ folder. You should change loglevel property (as far as I remember it should be 4 for debug). And then there should be a log file created in the same folder or in webdav folder. You can try to find exact error message in this log file and post it here.
I recently moved a project from TFS2008 to 2010, and I'm having trouble getting the 2010 build scripts to work. I managed to make the script run using the the upgrade template, but I'm running into the following error:
TF204001: The item $/blah/blah/blah/TFSBuild.proj cannot be downloaded. Read permission is required to retrieve the content.
I can't figure out what needs this permission (my account? The build daemon? I assume the latter), nor how to grant them. Any ideas?
I had the same issue and solved as follows:
The build agent account needs 2 permissions: Read and Label
You need to map you Team Collection Folder to a local folder and give the build agent account both permissions, above.
Make sure the templates for the builds are also there and with identical permissions.
I hope this helps.
I have an uninstall issue with an app which is using sqlite: during installation a blank sqlite db is created in [CommonAppData]\MyApp\mydb.sqlite, e.g. C:\Documents and Settings\All Users\Application Data\MyApp\mydb.sqlite. When I uninstall my app it can't delete the sqlite db, despite it removing the applications that are connectng to it. Using process explorer I can see that it's explorer.exe that has a lock on the MyApp folder (not on the sqlite file).
I've not seen this sort of thing before. Is it possible this is caused by the app not correctly closing/disposing of connections? I understand that at some level windows manages the fact that several threads & processes are accessing my db file, and it handles the locking. Is it possible that if my app isn't closing connections etc correctly then windows gets confused about whether the file is locked or not?
Or is that not possible and it must simply be something wrong with my MSI?
thanks for any suggestions!
UPDATE: not only can I not delete the folder or file, if I create a new file in that folder (e.g. a new txt doc) I can then not delete that file! So it's some wacky lock on the folder....
UPDATE: actually...it might just be permissions on that folder! In my msi i was setting permissions on that folder, and I think I didn't give delete rights so when I uninstalled I didn't have access to delete it :-/
Use handle.exe from the SysInternals collection to find out what has the remaining handle to the file.
It could also be your MSI, so check you are doing things in the right order by doing;
msiexec /u mymsi.msi /lv* mylog.txt
How can I change an SQLite database from read-only to read-write?
When I executed the update statement, I always got:
SQL error: attempt to write a readonly database
The SQLite file is a writeable file on the filesystem.
There can be several reasons for this error message:
Several processes have the database open at the same time (see the FAQ).
There is a plugin to compress and encrypt the database. It doesn't allow to modify the DB.
Lastly, another FAQ says: "Make sure that the directory containing the database file is also writable to the user executing the CGI script." I think this is because the engine needs to create more files in the directory.
The whole filesystem might be read only, for example after a crash.
On Unix systems, another process can replace the whole file.
I solved this by changing owner from "root" to my own user, on all files in Database's folder.
Just do ls -l on said folder, and if any of the files is owned by root, just change it to your user, like:
# For each file do:
sudo chown "$USER":"$USER" /path/to/my-folder/file.txt
# Or "R"ecursive.
sudo chown -R "$USER":"$USER" /path/to/my-folder
(this error message is typically misleading, and is usually a general permissions error)
On Windows
If you're issuing SQL directly against the database, make sure whatever application you're using to run the SQL is running as administrator
If an application is attempting the update, the account that it uses to access the database may need permissions on the folder containing your database file. For example, if IIS is accessing the database, the IUSR and IIS_IUSRS may both need appropriate permissions (you can try this by temporarily giving these accounts full control over the folder, checking if this works, then tying down the permissions as appropriate)
This error usually happens when your database is accessed by one application already, and you're trying to access it with another application.
To share personal experience I encountered with this error that eventually fix both. Might not necessarily be related to your issue but it appears this error is so generic that it can be attributed to gazillion things.
Database instance open in another application. My DB appeared to have been in a "locked" state so it transition to read only mode. I was able to track it down by stopping the a 2nd instance of the application sharing the DB.
Directory tree permission - please be sure to ensure user account has permission not just at the file level but at the entire upper directory level all the way to / level.
Thanks
If using Android.
Make sure you have added the permission to write to your EXTERNAL_STORAGE to your AndroidManifest.xml.
Add this line to your AndroidManifest.xml file above and outside your <application> tag.
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
This will allow your application to write to the sdcard. This will help if your EXTERNAL_STORAGE is where you have stored your database on the device.
On win10 after a system crash, try to open db with DB Browser, but read only.
Simply delete the journal file.
In Linux command shell, I did:
chmod 777 <db_folder>
Where contains the database file.
It works. Now I can access my database and make insert queries.
On Windows:
tl;dr: Try opening the file again.
Our system was suffering this problem, and it definitely wasn't a permissions issue, since the program itself would be able to open the database as writable from many threads most of the time, but occasionally (only on Windows, not on OSX), a thread would get these errors even though all the other threads in the program were having no difficulties.
We eventually discovered that the threads that were failing were only those that were trying to open the database immediately after another thread had closed it (within 3 ms). We speculated that the problem was due to the fact that Windows (or the sqlite implementation under windows) doesn't always immediately clean up up file resources upon closing of a file. We got around this by running a test write query against the db upon opening (e.g., creating then dropping a table with a silly name). If the create/drop failed, we waited for 50 ms and tried again, repeating until we succeeded or 5 seconds elapsed.
It worked; apparently there just needed to be enough time for the resources to flush out to disk.
On Ubuntu, change the owner to the Apache group and grant the right permissions (no, it's not 777):
sudo chgrp www-data <path to db.sqlite3>
sudo chmod 664 <path to db.sqlite3>
Update
You can set the permissions for group and user as well.
sudo chown www-data:www-data <path to db.sqlite3>
If <db_name>.sqlite-journal file exists in the same folder with DB file, that means your DB is opened currently and in the middle of some changes (or it had been at the moment when DB folder was copied). If you try to open DB at this moment error attempt to write a readonly database (or similar) could appear.
As a solution, wait till <db_name>.sqlite-journal disappears or remove it (is not recommended on the working system)
I had this problem today, too.
It was caused by ActiveSync on Windows Mobile - the folder I was working in was synced so the AS process grabbed the DB file from time to time causing this error.
On Linux, give read/write permissions to the entire folder containing the database file.
Also, SELinux might be blocking the write. You need to set the correct permissions.
In my SELinux Management GUI (on Fedora 19), I checked the box on the line labelled httpd_unified (Unify HTTPD handling of all content files), and I was good to go.
I'm using SQLite on ESP32 and all answers here are "very strange"....
When I look at the data on the flash of the ESP I notice there is only one file for the whole db (there is also a temp file).
In this db file we have of course the user tables but also the system tables so "sqlite_master" for example which contain the definiton of the tables.
So, it's seems hard to belive this can be a "chmod" problem, because if the file is read only, even creating table would be impossible as SQLite would be unable to write the "sqlite_master" data...
So I think our friend user143482 is trying to acesse a "read only" table. In SQLite source code we can see a function named tabIsReadOnly with this comment:
/* Return true if table pTab is read-only.
**
** A table is read-only if any of the following are true:
**
** 1) It is a virtual table and no implementation of the xUpdate method
** has been provided
**
** 2) It is a system table (i.e. sqlite_master), this call is not
** part of a nested parse and writable_schema pragma has not
** been specified
**
** 3) The table is a shadow table, the database connection is in
** defensive mode, and the current sqlite3_prepare()
** is for a top-level SQL statement.
*/
SO ... here is the scenario ... i have a workflow on a document library that copies a file to a windows directory ... this workflow is set to be started at the time when a new item is added to the document library ... so everything works fine when you are manually uploading files to the doc library ... but the problem occurs when we use emails to populate the doc library instead of the manual uploading of files.
When an email is received ... the workflow starts successfully and runs properly (i have kept workflow history entries to check every section of code is being executed or not) ... the workflow stops when the section where the file is being copied to the windows folder is reached.
I basically think this is a problem with the permissions or access issues. Because when we upload the file manually (i.e. from doc library > upload) everything works fine. But maybe there is some other permission set which is used while an email is received by the doc library ... i have tried by assigning permissions to "Everyone" on the windows folder ... but no luck...
Can someone let me know which windows user account is used when an email is received by a document library? (i think its the IIS default account - but isnt it included in Everyone?? )
One solution which i can devise in my mind is that for the file transfer to the windows folder i should use temporary impersonation for the specific code segment (which writes the doc library file to windows folder) but any suggestions are welcome.
P.S. I dont have access to the server right now so i can only devise approaches in my mind ... cant test them right nw... so it would be good to have all suggestions u have so that once i get the access i can try all stuff :D
This is a well known situation. The system does not know who sent the email so it cannot impersonate a user it has no knowledge about.
Depending on which version of SharePoint you are running, the workflow may not start at all or it may start under the account that published the workflow.
For details see this Microsoft Support Article.