Problem scenario: You’ve downloaded a file from t3h intranetz on your Snow Leopard MacBook, and opens the file (possibly a PDF or DMG file) using the Mac. Then you try to copy the file to your SMB/CIFS network share (Samba/Synology/QNap/ReadyNAS/{your NAS device here}), but get the following dreaded and dumbfounding error message:

The operation can’t be completed because you don’t have permission to access some of the items.

The problem here, is that the file has been modified by OSX. Now, after having been tampered with by your Mac, the file contains more attributes, which you can display using the ‘xattr {file}’ command in a terminal window. A file with extended permissions might look like this:

$ xattr Pictures/Avatar/cookie-monster3-7769871237963363.jpg
com.apple.metadata:kMDItemWhereFroms
com.apple.quarantine

$ xattr -d com.apple.quarantine

Note that you would have to do this process for every extended attribute the file has.

Well, back to the problem. In order to make Samba ignore the extended attributes, you could add the following to your smb.conf Samba configuration file (I’d put it in the [global] section):

[global]
unix extensions = no

Do a restart of the Samba daemon on the server, remount the service shares on your Mac, and everything should be back to normal. At least, that’s my experience this far .

Happy hacking!

From: n j
To: Martin McCormick <martin@dc.cis.[obfuscateddomain].edu>
Cc: freebsd-questions@freebsd.org

When a System Dies; Getting back in operation again.

> … What is the best way to restore the full system?
> Can I use the FreeBSD installation disk in rescue mode?

I experienced such a situation just 2 weeks ago. My primary problem was that I had to do restore over the network (no attached tape drives, no external HDDs). I wanted to use ssh to grab the dump from the backup server, but ended up using netcat which worked great.

Here’s basically what I did including backup from the not-yet-dead machine (note, I used intermediate backup server, but it should be possible to directly pipe dump to restore):

1. dump -0Laf – / | ssh backup-server “cat > dump.root”
2. boot the new machine from CD disc1 (FreeBSD <7) or livefs disc (FreeBSD >7)
3. create and newfs partitions as explained in this thread (at least the size of backup, can be larger)
4. go into the rescue (fixit) mode, create mount points for created partitions (mkdir mnt.root), mount partitions (e.g. mount /dev/da0s1a /mnt.root), change directory to mount point (cd /mnt.root), configure NIC (ifconfig)
5. start netcat (nc -l 55555 | restore -rvf -)
6. on backup-server: cat dump.root | nc new-machine 55555
7. repeat for usr and var partitions

Notes:

1. if security is an issue, ssh out from the new machine to the backup server with port forwarding (ssh -R 55555:localhost:55555 backup-server) and pipe the backup to localhost (cat dump.root | nc localhost 55555); my initial idea was to start sshd in fixit mode (see my post to the list “fixit console with sshd”) which turned out to be too much of a trouble.
2. restore uses TMPDIR to store some temporary files during restore process; the fixit mode has limited free space and when it gets exhausted the restore process will fail, so it is a good idea to use an available partition as a temporary TMPDIR (e.g. export TMPDIR=/mnt.var while restoring usr partition and later use a subdirectory of usr as TMPDIR to restore var partition)
3. [IMPORTANT!] after the restore process is over, manually check restored etc/fstab and etc/rc.conf (currently mounted as /mnt.root/…) to fix:
   1. partition names (e.g. /dev/da0s1a might become /dev/amrd0s1a)
   2. ethernet interface names (e.g. em0 might become bge0)
   3. IP addresses in case you still have the old box running to avoid IP conflict

You should now be able to safely reboot and log into your new machine.

Regards,
–
Nino