In my home directory, there are two files called ._Desktop
and ._Library
. They have read and write permissions, but cannot be read, even with root.
What do these files do? Is there any way to modify them?
macosnfs
In my home directory, there are two files called ._Desktop
and ._Library
. They have read and write permissions, but cannot be read, even with root.
What do these files do? Is there any way to modify them?
There are a number of possible pitfalls to having an encrypted home folder; most of them are more-or-less intrinsic to the idea, so they're not likely to go away... ever.
UPDATE: Lion's FileVault 2 uses full-volume encryption rather than just home-directory, so it actually does make some of these issues go away and changes several others. I've added notes in [] below. Note that upgrading to Lion does not automatically convert to FV2; you must first turn off "Legacy FileVault" encryption for accounts using the old system, then turn on VF2 to reencrypt.
Speed: obviously, the computer has to decrypt the data to read it from disk, and encrypt it before reading from disk, which'll slow down disk access. This usually isn't a big deal unless you're doing something like video editing. There's also a delay at logout as it recovers space in the image (and maybe also backs it up; see below). [VF2 removes the logout delay, and can use hardware AES instructions (on CPUs that support them) to minimize the general slowdown.]
Too much security: the good thing about FileVault is that nobody can get at your data without your login password (of the computer's master password). The bad thing is that if you forget your password (and don't remember/haven't set a master password), you can't get at your data either. The recommended procedure is to set a master password (before enabling FileVault), write it down, and store the written copy someplace secure (e.g. sealed envelope in a safe deposit box). [VF2 creates a recovery key, which functions very similarly to the old master key. There's also an option to have Apple store the recovery key for you, although I'd recommend using that in addition to (not instead of) storing the key yourself.]
File non-sharing: FileVault security prevents you from sharing files out of your home folder. Your Public folder, normally accessible by other users on the computer (and if you have file sharing turned on, other computers on the network) is locked in the FileVault and available only to you. [FV2 removes this limitation.]
Risk of data corruption: normally, if your computer crashes there's a possibility that whatever files you had open could get corrupted; with FileVault, your entire home folder is contained in a disk image, and if that gets corrupted you could lose everything. IIRC both OS X v10.3.0 and 10.4.0 shipped with bugs that could corrupt the types of images used by FileVault (fixed in 10.3.1 and 10.4.1, but still...). So backup is very important if you have data you don't want to lose. [FV2 does not have the image corruption issue, but is still vulnerable to normal volume corruption; it will also limit your options for data recovery somewhat, as not all volume repair/recovery tools support encrypted volumes (yet).] Speaking of which:
Backup time: backing up the FileVault image file is generally only possible when you're logged out. External volumes (like backup drives) get dismounted when nobody's logged in, creating a bit of a catch-22 for many backup systems. Time Machine gets around this by doing a backup as you log out (after the image becomes accessible, but before the backup drive gets dismounted), so make sure you log out with the backup drive attached from time to time. Other backup systems... who knows. In any case, test to make sure you're actually getting a useable backup. [FV2 removes this limitation. Note that Time Machine under Lion supports encrypting the backup volume, in which case it can only back up when the backup volume is mounted and decrypted.]
Backup capacity: backup systems generally save space by only backing up files that've changed since the last backup. With your files hidden in a disk image, this isn't really possible. The image is stored as a series of "band" files (in "sparse bundle format"), so the backup system only needs to store the bands that changed, but since these don't neatly correspond to specific files in your home folder, it's still going to use more space than if it could back up the files directly. [FV2 removes this limitation.]
Backup recovery: since the files you're likely to want to recover from a backup are hidden inside the encrypted image, they're a lot less convenient to recover from backup. When using Time Machine, its slick view-through-time interface doesn't work with FileVault-protected files, you have to find the backup of the image, mount it, and recover the file(s) you want by hand. Similarly, if you want to recover a file from an online backup, you're likely to have to recover the entire image so you can mount it and pull out the file(s) you want. [FV2 removes this limitation.]
One more note: to keep people from bypassing FileVault, make sure you have secure (encrypted) virtual memory enabled (in System Preferences -> Security pane -> General tab), and either log out consistently (yeah, right) or require a password immediately after sleep or screen saver (same place) and set the screen saver to run automatically when the computer's been idle for a while. There is an option to automatically log out after a period of inactivity, but this doesn't always work (a program with unsaved documents will generally prevent logout). [FV2 encrypts the virtual memory swap along with everything else, although the advice about locking or logging off still applies. Also, 10.7.0-10.7.1 were vulnerable to FireWire DMA attacks in some states, but this appears to have been fixed in 10.7.2.]
I've been interested in this question since Nov 2012 and even set up a FreeNAS VM to reproduce the issue.
I eventually gave up but since the question has been resuscitated I will share what I found out back then and in the last hours (luckily I didn't delete the VM) and what I think the cause for this issue is. I have also found a workaround.
First of all, this is my test setup:
OS X 10.8.2 (sorry, no 10.7.5 around).
FreeNAS (FreeBSD 8.2-RELEASE-p1)
(The OP's version is FreeBSD 8.2-RELEASE-p7 - I couldn't find the same version.)
A NAS filesystem in /mnt/raid
:
A user named netboot
:
An AFP filesystem (/mnt/raid/netboot
) exported as netboot
:
(Note that it is configured read-only).
An NFS filesystem (same path as AFP filesystem, to match the OP's configuration: /mnt/raid/netboot
):
I mounted the AFP read-only filesystem as user netboot
using the Finder with ⌘K:
and mounted a DMG image file without any problems:
$ sudo rm /private/var/netboot/Library-Shadow
$ sudo /usr/bin/hdiutil attach /Volumes/netboot/p7zip-9.04-0.i386.dmg -notremovable -shadow /private/var/netboot/Library-Shadow -owners on -noverify -noautofsck -nobrowse
Password:
/dev/disk3 Apple_partition_scheme
/dev/disk3s1 Apple_partition_map
/dev/disk3s2 Apple_HFS /Volumes/p7zip.pkg
Then I unmounted it and mounted the read-only NFS filesystem (I also used ⌘K) and couldn't mount the DMG image file.
I think the problem is logged here:
CBSDBackingStore::setPermission: opening /Volumes/netboot/Lion.nbi/Library.dmg
CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000000 -> 0x00000014 (locks are MANDATORY)
CBSDBackingStore:OpenLockFriendly: could not open with lock 30
Error 30 means (see man 2 intro
):
30 EROFS Read-only file system. An attempt was made to modify a file or directory was made on a file system that was read-only at the time.
No surprise here, it is indeed a read-only filesystem, but... when mounted over AFP it works, why?
Because Apple's NFS implementation has some problems with locking. As stated in this post at gluster.org:
OS X does a phenominal amount of file locking (some would say, needlessly so) and has always been really sensitive to the configuration of locking on the NFS servers. So much so that if you randomly pick an NFS server in a large enterprise, true success is pretty unlikely.
In my setup, the NFS server (that is, the FreeNAS VM) was suddenly irresponsive (from my Mac's /var/log/system.log
):
Mar 15 15:35:04 avallone.local rpc.lockd[8119]: Lockd got unexpected signal 20
Mar 15 15:35:04 avallone com.apple.launchd[1] (com.apple.lockd[8119]): Exited with code: 1
Mar 15 15:35:04 avallone com.apple.launchd[1] (com.apple.lockd): Throttling respawn: Will start in 10 seconds
(...)
Mar 15 15:35:07 avallone com.apple.launchd[1] (com.apple.statd[8121]): Exited with code: 1
Mar 15 15:35:07 avallone com.apple.launchd[1] (com.apple.statd): Throttling respawn: Will start in 10 seconds
Mar 15 15:35:13 avallone kernel[0]: nfs server 172.16.54.186:/mnt/raid/netboot: lockd not responding
Mar 15 15:35:13 avallone.local KernelEventAgent[72]: tid 00000000 received event(s) VQ_NOTRESP (1)
Mar 15 15:35:13 avallone.local KernelEventAgent[72]: tid 00000000 type 'nfs', mounted on '/Volumes/netboot', from '172.16.54.186:/mnt/raid/netboot', not responding
(...)
Mar 15 15:35:34 avallone.local KernelEventAgent[72]: tid 00000000 unmounting 1 filesystems
The output of sudo /usr/bin/hdiutil attach -debug /Volumes/netboot/p7zip-9.04-0.i386.dmg -notremovable -shadow /private/var/netboot/Library-Shadow -owners on -noverify -noautofsck -nobrowse
was:
CBSDBackingStore::setPermission: opening /Volumes/netboot/p7zip-9.04-0.i386.dmg
CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000000 -> 0x00000014 (locks are MANDATORY)
CBSDBackingStore:OpenLockFriendly: could not open with lock 5
Error 5 means (again from man 2 intro
):
5 EIO Input/output error. Some physical input or output error occurred. This error will not be reported until a subsequent operation on the same file descriptor and may be lost (over written) by any subsequent errors.
which isn't suprising at all, the NFS filesystem was gone.
A workaround (tested on OS X 10.8) is to mount NFS with options nolocks,locallocks
. As explained in the post at gluster.org already mentioned:
Fortunately, there is a fix: just turn off network locking. You can do it by adding the "nolocks,locallocks" options in the advanced options field of the Disk Utility NFS mounting UI, but this is painful if you do a lot of them, and doesn't help at all with /net. You can edit /etc/auto_master to add these options to the /net entry, but it doesn't affect other mounts - however I do recommend deleting the hidefromfinder option in auto_master. If you want to fix every automount, edit /etc/autofs.conf and search for the line that starts with AUTOMOUNTD_MNTOPTS=. These options get applied on every mount. Add nolocks,locallocks and your world will be faster and happier after you reboot.
I manually mounted 172.16.54.186:/mnt/raid/netboot
and it worked flawlessly:
$ sudo rm /private/var/netboot/Library-Shadow
$ sudo mount -o nolocks,locallocks,ro 172.16.54.186:/mnt/raid/netboot /tmp/mnt
$ sudo /usr/bin/hdiutil attach /tmp/mnt/p7zip-9.04-0.i386.dmg -notremovable -shadow /private/var/netboot/Library-Shadow -owners on -noverify -noautofsck -nobrowse
/dev/disk6 Apple_partition_scheme
/dev/disk6s1 Apple_partition_map
/dev/disk6s2 Apple_HFS /Volumes/p7zip.pkg
I also edited /etc/auto_master
like this:
+auto_master # Use directory service
#/net -hosts -nobrowse,hidefromfinder,nosuid
/net -hosts -nosuid,nolocks,locallocks
/home auto_home -nobrowse,hidefromfinder
/Network/Servers -fstab
/- -static
stopped and started automountd
and autofsd
:
$ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.automountd.plist
$ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.autofsd.plist
$ sudo launchctl load /System/Library/LaunchDaemons/com.apple.autofsd.plist
$ sudo launchctl load /System/Library/LaunchDaemons/com.apple.automountd.plist
and worked like a charm:
$ cd /net/172.16.54.186/mnt/raid/netboot
$ ls
Network Trash Folder Temporary Items p7zip-9.04-0.i386.dmg
$ sudo rm /private/var/netboot/Library-Shadow
$ sudo /usr/bin/hdiutil attach p7zip-9.04-0.i386.dmg -notremovable -shadow /private/var/netboot/Library-Shadow -owners on -noverify -noautofsck -nobrowse
/dev/disk7 Apple_partition_scheme
/dev/disk7s1 Apple_partition_map
/dev/disk7s2 Apple_HFS /Volumes/p7zip.pkg
Best Answer
._ Desktop
and._Library
contain extended attributes for these directories. This StackOverflow question describes roughly what generic._
files are.As to why directories like
Desktop
orLibrary
would need extended attributes is beyond me, though I would guess it has something to do with appearance and special files.If these
._
files are appearing on a mounted network filesystem (i.e. NFS) that doesn't use HFS+ on the host server, that is because HFS+ would usually store the information found inside these._
files along with the file itself. However, since other filesystems do not handle these extended attributes nicely, OS X creates a resource fork that allows your client-side HFS+ filesystem to see extended attributes as if they were part of the file itself.These files are used in the AppleDouble format which cause the file itself and its pesky counterpart to be merged once the file is taken off the networked filesystem and placed onto a HFS+ filesystem. Deleting these
._
file metadata counterparts would usually result in their regeneration the next time OS X processes the file itself.credit to Tetsujin's comment