[X4U] Permissions, Networking and Lion

[David Ledger]

At 12:19 -0500 8/2/12, jetlag11 at mac.com wrote:
>On Feb 7, 2012, at 5:42 PM, David Ledger wrote:

>When you connect to the other Mac, if you do so as the user that 
>owns the files and folders you want to access, there should be no 
>problem. Copying a file across and getting an empty file means that 
>the destination folder is writable by the user doing it, so the file 
>is created, but the file gets permissions that don't allow the user 
>to write the contents into it. We need to know more to diagnose the 
>problem. Have you made any changes to try to help the situation?
>===============
>David -

>Thank you for your assistance. I have two Macs (that we're talking 
>about): early MacBook (MB) running 10.6.8 where I'm user J1, and 
>recent Mini (Mini) running 10.7.3 where I'm J2. I want to be able to 
>freely move and modify Documents folder items between the two 
>systems. They're connected over a local network.

>(1 10.6->10.7) Today, I was sitting at Mini as J2. I remotely 
>successfully logged into MB as J1, and J1's document folder contents 
>displayed. I copied file J1-1 to Mini successfully but, while its 
>permissions on J1 were rw, rw, rw, the copied file on Mini had 
>permissions rw, rw, r. The file opened correctly on Mini & I could 
>modify it and save it. Why did the permissions change?

Every Unix process has  a variable property called 'umask'. It's a 
number that when viewed in binary has a bit position for every bit of 
a POSIX permissions setting. rw, rw, rw in the Finder Info is 
translated from a Unix OSIX permission of rw-rw-rw-, which is a 
humanly more understandable of the binary number 110110110. The 'r's, 
'w's and '-'s come from the position of the bit in the number, and it 
showing as r/w/x or '-' comes from the bit being 1 or 0. So the 
protection is held as just 9 bits of a number thats kept in the data 
that describes the file. When a file is created the protection bits 
of the new file are set to the-9-bits-you-might-expect logical AND'd 
with the inverse of the umask. In your case the source file has 
protection bits 110110110 so the-9-bits-you-might-expect would be the 
same -
110110110. If the umask is 000000010 (decimal 2, which is common), 
its inverse is
111111101 and if you AND those two together (only a 1 where both are 1) you get
110110100 which is displayed in Unix as rw-rw-r-- and in the Finder 
info as rw, rw, r.
So umask is a way of saying (with a value of 2) 'don't make any file 
I create writable by Other. This is quite a reasonable thing to do in 
most cases and so is the default.

If the file is being copied by J2, the new file should be created by 
J2 and hence owned by J2. In that case the first group of permissions 
apply, which are rw and so J2 can write the contents into it. If J2 
can't then I suspect that either the file already existed created by 
some other user, or for some reason the source ownership is being 
applied to the destination (a bug), or there's some ACL (Access 
Control List) present that is overriding POSIX protection. (ACLs are 
a kludge to make Unix protection work more flexibly, but the same 
control can usually be done with careful directory hierarchies and 
use of groups).

>(2 10.7->10.6) Still sitting at Mini as J2 and connected to MB as 
>J1, I tried to copy file J2-A to MB. File permissions on J2 were rw, 
>rw, rw. Before doing this, I went downstairs to MB and changed the 
>permissions in J1's Documents folder to rw, rw, rw and applied to 
>enclosed items. Back upstairs to Mini. The file, J2-A, copied over 
>at zero length. Still at Mini, I was allowed to delete J2-1 from MB 
>without an admin password & apparently successfully.

Umask would also apply there, with the same 3 possibilities for the 
reason. Bug being a likely one.

>
>But when I tried to repeat the copy - copy J2-A to J1 on the MB 
>while sitting at Mini - my admin password was required. This dialog 
>box then appeared:
>"A newer item named ³20120208 Letter of Retirement.pdf² already 
>exists in this location. Do you want to replace it with the older 
>one you¹re moving?" with Keep Both Files, Stop, & Replace as the 
>three buttons.
>
>Clicked Replace and this appeared: "The operation can¹t be completed 
>because an item with the name ³² already exists." I got rid of this, 
>end of story - NOT. On MB, file J2-A appeared, again, and again with 
>zero length.
>
>(In the past, I selected Keep Both Files which would generate tens 
>of thousands of zero length copies.)
>
>My first conclusion is that file transfers from Lion to Snow Leopard 
>don't work.
>
>My second conclusion is that I need a better understanding of 
>permissions under Lion that I have acquired in the preceding 17 
>years. Or Lion has a permissions bug.

When I get a chance I'll do some tests.

David


-- 
David Ledger - Freelance Unix Sysadmin in the UK.
HP-UX specialist of hpUG technical user group (www.hpug.org.uk)
david.ledger at ivdcs.co.uk
www.ivdcs.co.uk