I'm trying to:
sudo tar xpzf mira-2044-x86_64-Darwin.tgz -C /
I am in the correct directory (my Downloads folder) but I get this error:
./usr/: Can't set user=0/group=0 for usrCan't update time for usr
tar: Error exit delayed from previous errors.
What does this error mean in this context?
Option p of tar means preserve permissions.
tar is attempting to set file permission, ownership and modification time of some existing directories. In MacOS, /usr is owned by root:wheel but the archive has it owned by root:root.
Unfortunately, when running tar as superuser, the default is to preserve permissions. So you cannot turn this off.
Fortunately, k option of tar will skip overwriting existing files or directories. You can tell tar not to overwrite /usr, /usr/local, /usr/local/bin and any directories that you already have.
Modification time is always restored when a file or directory is restored. Option k will already prevent modification time to get updated when it tells tar not to overwrite existing directories/files. It is still better to know that the option m tells tar not to update the modification time of a file/directory.
You should now be able to install miranda by running:
sudo tar xmpkvzf mira-2044-x86_64-Darwin.tgz -C /
That added v (verbose) option is just to let you see what are being extracted.
Related
Is there a way to chmod 777 the contents of a tarfile upon creation (or shortly thereafter) before distributing? The write permissions of the directory that's being tar'd is unknown at the time of tar'ing (but typically 555). I would like the unrolled dir to be world writable without the users who are unrolling the tar to have to remember to chmod -R 777 <untarred dir> before proceeding.
The clumsy way would be to make a copy of the directory, and then chmod -R 777 <copydir> but I was wondering if there was a better solution.
I'm on a Solaris 10 machine.
BACKGROUND:
The root directory is in our ClearCase vob with specific file permissions, recursively. A tarfile is created and distributed to multiple "customers" within our org. Most only need the read/execute permissions (and specifically DON'T want them writable), but one group in particular needs their copy to be recursively writable since they may edit these files, or even restore back to a "fresh" copy (i.e., in their original state as I gave them).
This group is somewhat technically challenged. Even though they have instructions on the "how-to's" of the tarfile, they always seem to forget (or get wrong) the setting of the files to be recursively writable once untarred. This leads to phone calls to me to diagnose a variety of problems where the root cause is that they forgot to do (or did incorrectly) the chmod'ing of the unrolled directory.
And before you ask, yes, I wrote them a script to untar/chmod (specific just for them), but... oh never mind.
So, I figured I'd create a separate, recursively-writable version of the tar to distribute just to them. As I said originally, I could always create a copy of the dir, make the copy recursively writable and then tar up the copy dir, but the dir is fairly large, and disk space is sometimes near full (it can vary greatly), so making a copy of the dir will not be feasable 100% of the time.
With GNU tar, use the --mode option when creating the archive, e.g.:
tar cf archive.tar --mode='a+rwX' *
But note that when the archive is extracted, the umask will be applied by default. So unless the user's umask is 000, then the permissions will be updated at that point. However, the umask can be ignored by using the -p (--preserve) option, e.g.:
tar xfp archive.tar
You can easily change the permissions on the files prior to your tar command, although I generally recommend people NEVER use 777 for anything except /tmp on a unix system, it's more productive to use 755 or worst case 775 for directories. That way you're not letting the world write to your directories, which is generally advisable.
Most unix users don't like to set the permissions recursively because it sets the execute bit on files that should not be executable (configuration files for instance) to avoid this they invented a new way to use chmod some time ago, called symbolic mode. Reading the man page on chmod should provide details, but you could try this:
cd $targetdir; chmod -R u+rwX,a+rX .; tar zcvf $destTarFile .
Where your $targetdir is the directory you are tarring up and $destTarFile is the name of the tar file you're creating.
When you untar that tar file, the permissions are attempted to be retained. Certain rules govern that process of course - the uid and gid of the owner will only be retained if root is doing the untaring, but otherwise, they are set to the efective uid and gid of the current process.
Mac OS X Yosemite v.10.10.5.
I am trying to use the cp command to copy one Git directory to another.
This command-line statement:
cp -r /path/to/dir/from/ /path/to/dir/to/
Returns this error:
cp: /path/to/dir/to/.git/objects/00/00ad2afeb304e18870d4509efc89fedcb3f128: Permission denied
This error is returned one time each for (what I believe, but haven't verified, is) every file in the directory.
The first time I ran the command it worked properly, as expected, without error. But, without making any changes to any files, the second (and subsequent) times I ran the command, I got the error.
What's going on? And how can I fix this?
Edit:
In response to a question in the comment:
What does ls -l /path/to/dir/to/.git/objects/00/00ad2afeb304e18870d4509efc89fedcb3f128 show?
The answer is it shows:
-r--r--r-- 1 myusername staff 6151 May 6 00:45 /path/to/dir/to/.git/objects/00/00ad2afeb304e18870d4509efc89fedcb3f128
The reason you are getting Permission Denied is because you are trying to overwrite a file that already exists in the destination directory that has read only permissions set on it. Since it appears you're trying to overwrite it you could just remove the destination directory if it exists before the copy operation. Also you should use -R, not -r ...
Historic versions of the cp utility had a -r option. This
implementation
supports that option; however, its use is strongly discouraged, as it
does not correctly copy special files, symbolic links, or fifo's.
Using a command such as this should resolve your issue:
[[ ! -d dest ]] || rm -rf dest ; cp -R src dest
The above checks if dest exists; if it does recursively remove it, then copy the source to dest,
You may want cp -rp for this operation. -p preserves the user and group IDs associated with the file. Try starting over using -p and see if that solves the issue.
Anther reason you might be seeing this issue is if the permission really is denied. That is, if you're trying to copy into a folder owned by another user without superuser privileges.
I would like to compress a directory.
tar -cvzf mydir.tar.gz mydir
but this retains symlinks so that it is not portable to a new system.
How can I convert symlinks?
I have tried
tar -cvzfh
since man tar says
-h, --dereference
don’t dump symlinks; dump the files they point to
but this results in an error
tar: Error exit delayed from previous errors
and creates a file called "zh"
My files are on a RHEL server.
Your tar.gz file name must follow immediately after the -f flag, merely reordering the flags may work.
tar -cvzhf mydir.tar.gz mydir
My advisor frequently compiles a bunch of software into his /usr/local and then distributes his /usr/local as a tarball. I then extract the tarball onto our lab machines for our use. Until now, this has worked fine, we just replace the old /usr/local with the contents of the tarball.
But I have started installing my own software on these machines. If I delete /usr/local, obviously some of that software and config gets deleted as well.
Instead, how can I recursively copy files from the tarball into the corresponding directory in /usr/local?
For example:
tarball path filesystem path
------------ ---------------
local/bin/myprog -> /usr/local/bin/myprog
local/lib/mylib.so -> /usr/local/lib/mylib.so
etc.
Or is this a better question for ServerFault?
$ cd /usr
$ tar xvf f.tar
or
$ cd /tmp
$ tar xvf f.tar
$ cp -R local/. /usr/local/.
Although really, I think it should just go in some other directory, or in a subdir of /usr/local/. There isn't anything magical about /usr/local/ except perhaps a default PATH component.
The cp command has the -r flag for copying recursively:
$ cp -r local/* /usr/local/
Please look up your system's man page for cp for more information.
Use the k option and specify the destination to protect against overwriting files:
$ cd /usr
$ tar xvfk localtarball.tar local
local/
local/file
tar: local/file: Cannot open: File exists
local/bar2/
local/bar2/bar3
tar: local/file: Cannot open: File exists
local/bar2a/bar2aY/
tar: Error exit delayed from previous errors
After searching online, the best solution I've found so far is to just make a symbolic link in either "/Library/logs/" or "~/Library/logs/" to get it to show up in the Console application.
I'm wondering if it would be possible to add a new directory or log file to the "root" level directly under the "LOG FILES" section in the console.
Here's a quick screenshot:
There is one way to get your log files into the console.
You can add a symlink to the log file or log directory to one of the directories in the list. The directory ~/Library/Logs seems like the logical choice for adding your own log files.
For myself I wanted easy access to apache2 logs. I installed apache2 using macports and the default log file is located at /opt/local/apache2/logs.
Thus all I did was create the symlink to that directory.
# cd ~/Library/Logs
# ln -s /opt/local/apache2/logs/ apache2
Now I can easily use the console.app to get to the logs.
My solution for macOS Sierra:
First and last step, you must create a hard link from your source (log) directory into (as example) one of existing official log directories, you can seen in console.app.
I take my ~/Library/Logs directory for that.
hln /usr/local/var/log /Users/dierk/Library/Logs/_usr_local_var_log
Cross-posting this great tool for creating hardlinks originally posted by Sam.
Short intro:
To install Hardlink, ensure you've installed homebrew, then run:
brew install hardlink-osx
Once installed, create a hard link with:
hln [source] [destination]
I actually just came across this option that worked perfectly for me:
Actually if you open terminal and...
$ cd /Library/Logs
then sym-link to your new log directory. eg i want my chroot'ed apache logs as 'www'
$ ln -s /chroot/apache/private/var/log www
then re-open Console.app
drill down into /Library/Logs and you will find your sym-linked directory.
;-)
Mohclips.
http://forums.macosxhints.com/showthread.php?t=35680
In Terminal run this command... append any log file directories you want to add
defaults write com.apple.Console LogFolderPaths -array '~/Library/Logs/' '/Library/Logs/' '/var/log/' '/opt/local/var/log/'
Since Mavericks, symlink behavior as change so "ln - s" doesn't work anymore.
use hardlink-osx instead to create an hardlink to your directory (may be installed via homebrew)
Very old post I know but, this is the only way I could get it to work.
cd /Library/Logs
sudo mkdir log_files
sudo ln -s /Users/USERNAME/Sites/website/logs/* log_files
In mac os 10.11, you may not be able to link to folder of logs, but instead you need to link to each log of logs folder in side console.
ln -s /opt/local/apache2/logs/error_log ~/Library/Logs/Apache2/error_log
You can just open any text file with console.app and it will add and keep it. Folder's though, no luck on that yet.
I was able to hardlink the files into ~/Library/logs by running:
ln /usr/local/var/logs/postgres.log ~/Library/logs
Notice the absence of -s.
No luck for directories though.
OSX Sierra 10.12.6
Just tried to do something similar.
I enter this in terminal, while the Console.app was running.
sudo mkdir -p /usr/local/var/log/apache2
sudo mv /private/var/log/apache2 /usr/local/var/log/apache2/apache2-old
sudo ln -s /usr/local/var/log/apache2 /private/var/log/apache2
Now whenever I open the Console.app it crashes.
Really wish there was a way of adding log files in the files. You CAN do it by dragging and dropping a folder onto the Console.app (given it a directory path as an argument), but the added folder only displays its immediate contents and doesn't allow for recursively descending into folders.
---------EDIT BELOW----------
Nevermind I stupidly did something like this leading to infinite recursion in Console.app
sudo mkdir -p /usr/local/var/log/apache2
sudo ln -s /private/var/log/apache2/apache2 /usr/local/var/log/apache2
sudo mv /private/var/log/apache2 /usr/local/var/log/apache2/apache2-old
sudo ln -s /usr/local/var/log/apache2 /private/var/log/apache2
I don't believe it's possible.
If you're generating log files, you should generate them into one of the standard locations anyway, so this won't be an issue.