Ive got a program that runs on Mac OS 10.5.8. The program runs a continuous cycle where it mounts an image, installs a browser plugin and unmounts the image again. If I leave this program running I eventually end up in a situation where I get the following error "fork: resource temporarily unavailable". In the activity monitor I can see that several hundreds of processes called diskimages-helper are running. Does anyone know why this happens and how I can avoid it? Below are the commands I use during one cycle of the program.
# First I remove the plugin
rm -rf "/Library/Internet Plug-Ins/my.plugin"
# If the mount exists I unmount it
hdiutil unmount [mount] -force
# If that doesnt work I detach the device
hdiutil detach [device] -force
# Then I mount the image
hdiutil mount [image]
# I install the plugin
installer -package [package] -target /
# Unmount
hdiutil unmount [mount] -force
# And if necessary detach
hdiutil detach [device] -force
You need to always detach the disk image -- unmounting it unmounts the filesystem, but leaves disk image attached to a /dev/disk* entry, with a diskimages-helper process running to handle it. Note that hdiutil detach will take care of unmounting the volume for you (provided Disk Arbitration is running), so you can just skip the unmount step.
Related
I ran the following command to install Nix on my Mac:
sh <(curl -L https://nixos.org/nix/install) --daemon --darwin-use-unencrypted-nix-store-volume
And I got the following error:
error: refusing to create Nix store volume because the boot volume is
FileVault encrypted, but encryption-at-rest is not available.
Manually create a volume for the store and re-run this script.
See https://nixos.org/nix/manual/#sect-macos-installation
https://nixos.org/nix/manual/#sect-macos-installation says:
If you're using a recent Mac with a T2 chip, your drive will still be encrypted at rest (in which case "unencrypted" is a bit of a misnomer). To use this approach, just install Nix with:
sh <(curl -L https://nixos.org/nix/install) --darwin-use-unencrypted-nix-store-volume
If you don't like the sound of this, you'll want to weigh the other approaches and tradeoffs detailed in this section.
I don't have a mac with a T2 chip, so what do I do?
I found some related github issues, but no direct answer.
I chose to use the Use a separate encrypted volume suggestion as outlined in by Philipp Haussleiter:
This approach only works if you have a Disk that is formated with APFS (that should always be the case, if your OS is running of a SSD).
You can check this with:
% diskutil list | grep APFS
…
0: APFS Container Scheme - +250.8 GB disk1
…
Create another Volume on your Disk for NIX:
% sudo diskutil apfs addVolume disk1 'APFS' nix
Will export new APFS Volume "nix" from APFS Container Reference disk1
Started APFS operation on disk1
Preparing to add APFS Volume to APFS Container disk1
Creating APFS Volume
Created new APFS Volume disk1s6
Mounting APFS Volume
Setting volume permissions
Disk from APFS operation: disk1s6
Finished APFS operation on disk1
Your disk may not be named disk1s6. Find the name of your disk with:
% diskutil list | grep nix
4: APFS Volume nix 7.7 GB disk1s6
Again, your disk may not be named disk1s6.
Encrypt disk:
You need to enter a passphrase for the encryption. You have to
remember that passphrase once – you can add it to your key chain later
on. After that the disk encryption will start in the background.
% sudo diskutil apfs encryptvolume disk1s6 -user disk
Passphrase for the new "Disk" user (672C4CFF-34C6-4407-83ED-294C1C42E161):
Repeat passphrase:
Starting background encryption with the new "Disk" crypto user on disk1s6
The new "Disk" user will be the only one who has initial access to disk1s6
The new APFS crypto user UUID will be 672C4CFF-34C6-4407-83ED-294C1C42E161
Background encryption is ongoing; see "diskutil apfs list" to see progress
Setup Mount Point:
MacOS Catalina does not allow to create folders directly under your
Root Path /. But we can use another method to have MacOS create that
folder for us. To do this, we have to add an entry into the file
/etc/synthetic.conf:
% sudo bash -c 'echo nix >> /etc/synthetic.conf'
Now, the next time, the system starts, a mount point /nix will be
created. The next task is to have our Volume mounted at Boot.
Setup Mount:
For the Mount Configuration, we need to the UUID of the Volume. We can
find this via the diskutil tool (again, your disk may not be named
disk1s6):
% diskutil info /dev/disk1s6 | grep UUID
We must edit /etc/fstab with vifs:
% sudo vifs
(vifs behaves just like vi, so use vi commands to edit the file):
UUID=1D9389C1-5676-4077-88F5-8D5304A0B1A6 /nix apfs rw
(Your UUID will be different!)
Reboot. You will get a GUI prompt to enter your encryption passphrase,
and save it to the keychain.
I then ran:
sh <(curl -L https://nixos.org/nix/install) --daemon
The --darwin-use-unencrypted-nix-store-volume option isn't necessary because we have an encrypted volume now.
Hello I have a script that creates a MacOSX image and then copies stuff to it.
The script was tested and worked fine until I tried to implement it in a Travis build.
This is where things get interesting. The bit of code that is of interest is as follows:
hdiutil create "$dmg" -srcfolder tmp -fs HFS+ -format UDRW -volname Fiji -attach
cp resources/install-fiji.jpg /Volumes/Fiji/.background.jpg
This fails because I am working in a VM and the /Volumes directory is not shared by the VM. If I try listing the directory I get:
ls -la /Volumes
ls: VMware Shared Folders: Input/output error
Even though the hdiutil command did not fail and in fact happily reported:
/dev/disk1 GUID_partition_scheme
/dev/disk1s1 Apple_HFS /Volumes/Fiji
How can I get around this problem? Maybe mount on a different mount point?
OK, I've figured out that I can just mount to something else after the creation command
hdiutil create "$dmg" -srcfolder tmp -fs HFS+ -format UDRW -volname Fiji
mkdir /tmp/Fiji
hdiutil attach "$dmg" -mountpoint /tmp/Fiji
Running bash on windows 10, the simple syntax below works when I SSH to my webserver, but not when I exit out and am on my local machine. It doesn't give me an error, but I can see permissions are unchanged. I have to checked that I am set up as an administrator on my computer. Is this an error or is this just a consequence of the local operating system being windows? IF the later, it makes me question the value of using bash on windows if common operations such as this won't work.
$chmod 644 filename
To enable changing file owners & permissions, you need to edit /etc/wsl.conf and insert the below config options:
[automount]
options = "metadata"
Do this inside the WSL shell, potentially needing sudo to edit/create the file.
This may require restarting WSL (such as with wsl --shutdown which is a Windows command, not one within WSL) or the host machine to take effect. This has been possible since 2018:
You can now set the owner and group of files using chmod/chown and modify read/write/execute permissions in WSL. You can also create special files like fifos, unix sockets, and device files. We’re introducing new mounting options with DrvFs for projecting permissions onto files alongside providing new Linux metadata on files and folders.
[cite: Microsoft Dev Blog]
You can also temporarily re-mount a drive with the following commands:
sudo umount /mnt/c
sudo mount -t drvfs C: /mnt/c -o metadata
...but please note, the command only takes effect in session scope. If you exit current bash, you'll lose your settings (credit: answerer Amade).
Reference:
Automatically Configuring WSL
There was an update to WSL recently (source), which lets you change permissions to files (Insider Build 17063).
All you have to do is to run:
sudo umount /mnt/c
sudo mount -t drvfs C: /mnt/c -o metadata
Both Amades and Chaos answers are correct.
But it only works for local drives not for mapped network drives. Z: is one of my network drives. Same operation on /mnt/c/Users/xxx/ works fine.
$sudo mount -t drvfs Z: /mnt/z -o metadata
$touch test
$chmod +w test
chmod: changing permissions of 'test': Operation not permitted
This is a known issue, see drvfs: metadata (chmod\chown) possible for mounted SMB drives?
I just upgraded to Mac OS X Mavericks. I have a sparsebundle image which is mounted with the "quarantine" attribute, which prevents me from running any shell scripts on the volume. Here is what I get when I run "mount" in terminal:
/dev/disk1s2 on /Volumes/Source (hfs, local, nodev, nosuid, journaled, noowners, quarantine, mounted by crith)
I've tried running the following command on the sparsebundle image:
xattr -d com.apple.quarantine Source.sparsebundle
But, the volume is still mounting with the "quarantine" flag set! Any advice?
It looks like the token inside the sparsebundle is what causes the image to be mounted with the quarantine flag. To fix, run this:
xattr -d com.apple.quarantine Source.sparsebundle/token
I created an EC2 instance (Ubuntu 64 bit) and attached a volume from a publicly available snapshot to the instance. I successfully mounted the volume. I am supposed to be able to run a script from this attached volume using the following steps as explained in the tutorial:
Log in to your virtual machine.
mkdir /space
mount /dev/sdf1 /space
cd /space
./setup-script
The problem is that, when I try: ./setup-script I got the following message:
-bash: ./setup-script: No such file or directory
What is the problem ? How can I search for the ./setup-script in the whole machine ? I'm not very familiar with linux system. Please, help.
For more details about the issue: Look at my previous post:
Error when mounting drive
# Is it a script or an executable ?
file /space/setup-script
# Show us it is readable and marked executable
ls -l /space/setup-script
# Mark it executable
chmod a+x /space/setup-script
# Then try running it again? If you know it is shell script you can:
bash /space/setup-script
If still not working, then we get into why it wont execute.
grep space /proc/mounts
Does the options it have noexec ?
Try mount -o remount,exec /space now try your instructions again.
NOTE: All commands presume you are 'root' user or you can 'sudo' each command.
It is possible that you have mounted the wrong device. I've just recalled a trick you can use to find the device name of an EBS volume in Linux, since it is often different from the device name reported in the AWS console. First unmount the device in Linux, then detach it from the instance using the AWS console, so we go back to the original state. Now run this command in Linux:
cat /proc/partitions
The command will show the volumes currently attached. The next step is to attach the volume to the instance using the AWS console, and then to run that same command again in Linux. You should see an additional line appear. This line will tell you the name of the device to mount. For example, I get this output in my Ubuntu instance:
major minor #blocks name
202 1 8388608 xvda1
202 80 8388608 xvdf
The first line was already there before I attached the volume, so I know this is my root volume. The second line is the one that appeared, so in this case, the device to mount would be /dev/xvdf.