Windows Backup creates "locked" directory on SMB share

Question

Level 1

0 points

Windows Backup creates "locked" directory on SMB share

I'm trying to back up my Windows 7 laptop to my Mac Mini over SMB.

Normal non-backup file operations work okay, from the desktop: I can create folders, drag files, delete files, etc.

But Windows Backup fails, because it creates a directory on the SMB share that--despite ACLs--OS X won't let anyone create files within, or change the security settings. The only option is to rm -rf the directory.

The ACLs look like this (the directory Windows Backup creates is called 'MEGALITH'. I tried creating a parent directory (called 'Megalith') with inherited ACLs, but to no avail:

sarsen:Megalith root# ls -le .

total 0

drwx------+ 2 windowsbackupuser staff 68 Jan 8 12:49 MEGALITH

0: user:root inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,re adextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_i nherit

1: group:admin inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,re adextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_i nherit

2: user:_spotlight inherited allow list,search,file_inherit,directory_inherit

Even with these ACLs, I cannot chown the MEGALITH directory. Nor can I edit its ACLs in the Server window.

My SMB config is:

sarsen$ defaults read /Library/Preferences/SystemConfiguration/com.apple.smb.serve r

{

AclsEnabled = 1;

AllowGuestAccess = 0;

AllowNTLM2Auth = 1;

DOSCodePage = 437;

EnabledServices = (

disk

);

LocalKerberosRealm = "LKDC:SHA1.C5D430A59786EE0CC0515EEF37A77A538C6D612A";

NetBIOSName = sarsen;

ServerDescription = sarsen;

Workgroup = WORKGROUP;

"wins server" = (

{

}

);

}

And the error log says:

Jan 8 12:49:27 sarsen.nerdgod.com digest-service[711]: digest-request: init request

Jan 8 12:49:27 sarsen.nerdgod.com digest-service[711]: digest-request: init return domain: SARSEN server: SARSEN

Jan 8 12:49:27 sarsen.nerdgod.com digest-service[711]: digest-request: uid=0

Jan 8 12:49:27 sarsen.nerdgod.com digest-service[711]: digest-request: od failed with 2 proto=ntlmv1-with-v2-session

Jan 8 12:49:27 sarsen.nerdgod.com digest-service[711]: digest-request: user=SARSEN\\windowsbackupuser

Jan 8 12:49:27 sarsen.nerdgod.com digest-service[711]: digest-request kdc: ok user=SARSEN\\windowsbackupuser proto=ntlmv1 flags: NEG_KEYEX, ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM2, NEG_ALWAYS_SIGN, NEG_NTLM, NEG_SIGN, NEG_TARGET, NEG_UNICODE

Posted on Jan 8, 2013 1:07 PM

Reply

Answer 1

Best reply

nerdguy Author

Level 1

0 points

Jan 8, 2013 8:14 PM in response to nerdguy

This must be a bug.

The problem is that the backup folder is marked readonly (`attrib +R MEGALITH` in DOS terms)

Mountain Lion's smb will write the folder, mark it read only, and THEN try to put files in it.

It also marks it readonly using some inscrutable semantics that arent' ACLS and differ from the usual unix permissions.

This doesn't happen with the "real" Samba.

Reply

Answer 2

nerdguy Author

Level 1

0 points

Jan 9, 2013 11:31 AM in response to nerdguy

Today I learned about

ls -lO

and

chflags

SMB is setting the uchg "immutable" flag when you set the DOS attribute to +R (it also does '+H' the same way)

In Snow Leopard, you could change this behavior.

How do you change it in Lion?

Reply

Answer 3

nerdguy Author

Level 1

0 points

Jan 9, 2013 2:19 PM in response to nerdguy

For interoperability with Windows clients, this is absolutely 100% bad behavior:

http://support.microsoft.com/kb/326549

Note Unlike the Read-only attribute for a file, the Read-only attribute for a folder is typically ignored by Windows, Windows components and accessories, and other programs. For example, you can delete, rename, and change a folder with the Read-only attribute by using Windows Explorer.

The Read-only and System attributes is only used by Windows Explorer to determine whether the folder is a special folder, such as a system folder that has its view customized by Windows (for example, My Documents, Favorites, Fonts, Downloaded Program Files), or a folder that you customized by using the Customize tab of the folder's Properties dialog box. As a result, Windows Explorer does not allow you to view or change the Read-only or System attributes of folders. When a folder has the Read-Only attribute set it causes Explorer to request the Desktop.ini of that folder to see if any special folder settings need to be set. It has been seen where if a network share that has a large amount of folders set to Read-only, it can cause Explorer to take longer then what is expected to render the contents of that share while it waits on the retrieval of the Desktop.ini files. The slower the network connectivity to the share the longer this process can take to the point where Explorer may timeout waiting for the data and render nothing or appear to hang.

Note In some previous versions of Windows, you can change the Read-only attribute for folders by using the Properties dialog box for the folder, but no versions of Windows permit you to change the System attribute by using Windows Explorer.

Reply