I am new to install4j and am trying to change the file permission of a directory to 0750 on a project that I inherited. I am in the Define Distribution Tree screen, right click on the directory, select Edit Entry, and change the Unix mode to 750. I save the project. After running the new install (running as root), the file permission is set to 755 (default). Are there additional steps required? I looked for other spots where the file permission may have been explicitly set, but did not find any. Any ideas on what I did wrong and how to debug this? Thanks.
Related
I'm on a linux machine running vscode. I am trying to do some debugging but whenever I try to select the environment configuration I get the message, "Unable to create 'launch.json' file inside the '.vscode' folder ({0})."
I suspect it could be a permissions thing but when I try to run vscode as an elevated user I am warned not to. Instead it advises that I can change the user data directory. Will this fix my problem?
After some digging, it turns out that the .vscode directory is created inside the root folder of each project added to vscode. To resolve the problem I had to create the folder manually and give permissions for vscode to write to the directory.
I recently installed cygwin, and have been unable to find my passwd/etc file in order set to HOME. Is there any way to force cygwin to generate the file?
The /etc/passwd and group files are no longer generated by default, starting with Cygwin 1.7.34.
You can still generate them. Cygwin will use these files preferentially if present, by default, but only to cater to existing installs and special situations.
When these files are not present, Cygwin now uses the native Windows user management mechanisms: Active Directory where present, or SAM where not.
It is therefore recommended that you use this new mechanism to change your home directory. The easiest way I know of to do this is to add a line like this to your /etc/nsswitch.conf file:
db_home: /%H
That will change your Cygwin home directory to be equal to your Windows user profile directory. There are many other legal % tokens you can use here to achieve different results. See the previous link for details.
In my case, I set db_home: /%H in /etc/nsswitch.conf file, and change permission of my .ssh dirctory to "full control".
I upgraded my Fedora box a few days ago. I went from Fedora 18, to Fedora 20 using fedup. This morning I noticed that when I tried to delete a zip file from one of my directories, I couldn't. Then I tried to create a directory, and I couldn't. I had to use sudo.
The directory where this is happening is the /var/www/html directory, which is the root directory of my server. Before doing the update I could modify the contents of this directory without any problem. I don't remember, but I may have changed the permission of the directory at some point to allow me to do this. Is it possible that the upgrade modified the permission of the html directory?
Please note that I'm not asking how to gain permission again, I've already modified the permission in the html directory. I just want to know if the reason for this happening was that the upgrade modified the permission on that directory.
Thanks.
The /var/www/html directory on Fedora is owned by the httpd package so yes, if that package got updated, then the permissions for that directory will be reset to whatever the package specifies.
When I try to save a file to disc within a project directory, I get this error:
java.io.IOException: W:\\[projectname]\\.idea not found
Some research tells me, the (network) location is not writable.
I'm trying to write this file from phpstorm in windows 8.
The drive (W:) is a network drive to a linux machine.
The directory I try to write to is chowned to the same user and group as I connect with in windows.
This is a result of ls -alh:
drwxrwxrwx 2 correct-user correct-user
On Linux and other Unix-like operating systems files starting with a . are considered 'hidden files' by default. As such, when the Windows-based program creates it, it suddenly doesn't see it anymore right after since it's hidden, even though the creation was successful. You can fix this in your Samba config by adding the following line to the share configuration:
hide dot files = no
In my samba settings I added a veto files parameter. Removing this parameter allows me to write dot files again.
Samba describes this setting as follows:
This is a list of files and directories that are neither visible nor accessible
I've just installed kohana in my new project temp.loc
I type in the browser temp.loc and Environment Tests says:
Cache Directory The /work/temp.loc/wwwroot/application/cache/ directory is not writable.
Logs Directory The /work/temp.loc/wwwroot/application/logs/ directory is not writable.
I'm trying to change the path Kohana::$log->attach(new Log_File(APPPATH.'logs')); in bootstrap.php. BUt, after refreshing the browser, the Environment Test still shows the same path /work/temp.loc/wwwroot/application/logs/, the path is not refreshed. Why?
Don't change the location in bootstrap, that isn't needed. The reason you are receiving this error message is probably because those two directories aren't writable. If you are on Mac OSX or a linux environment you need to set those directory permissions to 777 i.e. "chmod 777 cache". Both are located on your application directory. This is a common issue that I have to resolve every time I install Kohana on a new server.