SOLVED backup to FreeNAS from Crashplan on Windoze via share

[ChuckM]

I'm trying to backup TO an SMB share mounted from my FreeNAS-9.10.1 NAS using the crashplan client (v4.7.0) from my Windows 7 box. When I select a folder on the FreeNAS share as a destination Crashplan reports "The backup engine does not have access to the given location". I can read, write and delete files and I can create and delete subdirectories manually on that share. Both FreeNAS and Win7 are up to date with all updates.

I can successfully back to a SMB share mounted from a Ubuntu 14.04 server. In frustration I installed FreeBSD 10.03 from scratch on another box and installed Samba 4.3.11 from a package. I *CAN* successfully back up to a SMB share mounted from that box!

In finally captured the network traffic and discovered that Crashplan does a number of tests before accepting a directory for backups. All but one of the tests appear to pass. The one that fails attempts to create a file that it had created earlier with a "disposition" of overwrite file if it exists, this fails with "permission denied". The same operation on SMB shared from both Ubuntu 14.04 and FreeBSD 10.03 completes without an error. It seems clear that I have a Samba configuration issue, but I'm at a complete loss of what it might be.

Does anyone have any ideas or a magic formula on how to configure Crashplan/FreeNAS to allow Crashplan to back TO FreeNAS from Windoze?

Thanks!
Chuck

 

[Ericloewe]

Sounds like an easy fix.

Make sure your permissions are setup according to best practices (@m0nkey_ has a few videos that take care of the basics). Once that is done, just manually edit the permissions of the folder you're going to use for backups to give the crashplan user (I assume it's going to be your own account) the required permission, as you normally would in a Windows environment.

 

[anodos]

Sounds like an easy fix.

Make sure your permissions are setup according to best practices (@m0nkey_ has a few videos that take care of the basics). Once that is done, just manually edit the permissions of the folder you're going to use for backups to give the crashplan user (I assume it's going to be your own account) the required permission, as you normally would in a Windows environment.

+1. It's a permissions problem. You can use "smbstatus" to check the user that crashplan is using to establish a tree connection, then modify permissions on your share to grant that user write permissions.

 

[ChuckM]

Sounds like an easy fix.

Make sure your permissions are setup according to best practices (@m0nkey_ has a few videos that take care of the basics). Once that is done, just manually edit the permissions of the folder you're going to use for backups to give the crashplan user (I assume it's going to be your own account) the required permission, as you normally would in a Windows environment.

Thanks for the pointer, I watched monkey_'s video and checked the permissions. The "everyone" user didn't have rights, but my user did. Just as a test I gave full rights to "everyone", my group and my user, but still no success.

Please note that I AM able to create and delete files as well as subdirectories manually as the same user. I installed Crashplan is installed per user so it's started by "%APP_DIR%\CrashPlanService.vbs". As a test I killed Crashplan using task manger, opened a dos box, verified that I can read/write directories and files on the share I'm trying to use and then manually started Crashplan. No joy, I still get "The backup engine does not have access to the given location".

Chuck.

 

[depasseg]

Crashplan on Windows used to have issues (as in "it couldn't") writing to windows shares because of the fact that the crashplan process was being run as a system user (instead of the logged in user). This might lead to a situation where you need to allow unauthenticated access (even "everyone" assumes that a user is logging in, right?).
This article talks about backup a windows share, but the same access might be relevant for writing to the share:
https://support.code42.com/CrashPlan/4/Backup/Backing_Up_A_Windows_Network_Drive

 

[ChuckM]

+1. It's a permissions problem. You can use "smbstatus" to check the user that crashplan is using to establish a tree connection, then modify permissions on your share to grant that user write permissions.

Thanks Anodos, I wasn't aware of the smbstatus command. smbstatus shows:

Code:

[root@freenas] /nonexistent# smbstatus

Samba version 4.3.11-GIT-UNKNOWN
PID     Username      Group         Machine            Protocol Version
------------------------------------------------------------------------------
7677      skip          skip          icore7.lan   (ipv4:192.168.123.117:49978) SMB2_10

Service      pid     machine       Connected at
-------------------------------------------------------
test_backup   7677   icore7.lan    Mon Sep 19 07:37:35 2016

Locked files:
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
7677         1000       DENY_NONE  0x100081    RDONLY     NONE             /mnt/main/test_backup   .   Mon Sep 19 07:40:58 2016

Task manager shows that Crashplan is running as the "Skip" user:

And the permissions of the SMB mount look like this:

The only permission that isn't set is "special"

But advanced shows all permissions are allowed:

Ideas? I'm out!

 

[Ericloewe]

Proper fix: Have crashplan use a separate account to do its job and give that account the relevant permissions (Ideal world)
Kludge: Make sure the default user (whatever FreeNAS calls it) does not have deny set. Deny takes priority over Allow if there's a conflict.

So, if anonymous is set to Deny, but everyone is set to Allow, access by anonymous is denied.

 

[ChuckM]

Thanks for the link depasseg,

That article is what got me started going down this path. I've installed Crashplan "per user" so it's not running as a service and it's definitely running as the user I expect.

Chuck

 

[anodos]

Thanks for the link depasseg,

That article is what got me started going down this path. I've installed Crashplan "per user" so it's not running as a service and it's definitely running as the user I expect.

Chuck

Increase logging verbosity, then reproduce the error and examiner /var/log/samba4/log.smbd.

 

[ChuckM]

Increase logging verbosity, then reproduce the error and examiner /var/log/samba4/log.smbd.

Thanks Anodos !! That pin pointed the problem.

The operation that failed was:

Code:

  get_ea_dos_attribute: file backups/.testWriteFolder760965842482795266/.testWriteFile760965842482795266 case 3 set btime Mon Sep 19 13:56:26 2016
...
[2016/09/19 13:56:26.229397,  5, pid=37613, effective(1000, 1000), real(0, 0)] ../source3/smbd/open.c:2612(open_file_ntcreate)
  open_file_ntcreate: attributes missmatch for file backups/.testWriteFolder760965842482795266/.testWriteFile760965842482795266 (22 0) (0100777, 0666)
...
[2016/09/19 13:56:26.229525, 10, pid=37613, effective(1000, 1000), real(0, 0)] ../source3/smbd/open.c:4814(create_file_unixpath)
  create_file_unixpath: NT_STATUS_ACCESS_DENIED

I googled for "open_file_ntcreate: attributes missmatch for file" and found this https://lists.samba.org/archive/samba/2005-November/113886.html . Sure enough the test filename starts with a dot and hide dot files was set in the share:

Code:

[test_backup]
    path = /mnt/main/test_backup
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    vfs objects = zfs_space zfsacl aio_pthread streams_xattr
    hide dot files = yes
    guest ok = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare

I added "hide dot files = no" to the Auxiliary Parameters for the share and now it's WORKING!

Whew!

Chuck

 

[anodos]

Thanks Anodos !! That pin pointed the problem.

The operation that failed was:

Code:

  get_ea_dos_attribute: file backups/.testWriteFolder760965842482795266/.testWriteFile760965842482795266 case 3 set btime Mon Sep 19 13:56:26 2016
...
[2016/09/19 13:56:26.229397,  5, pid=37613, effective(1000, 1000), real(0, 0)] ../source3/smbd/open.c:2612(open_file_ntcreate)
  open_file_ntcreate: attributes missmatch for file backups/.testWriteFolder760965842482795266/.testWriteFile760965842482795266 (22 0) (0100777, 0666)
...
[2016/09/19 13:56:26.229525, 10, pid=37613, effective(1000, 1000), real(0, 0)] ../source3/smbd/open.c:4814(create_file_unixpath)
  create_file_unixpath: NT_STATUS_ACCESS_DENIED

I googled for "open_file_ntcreate: attributes missmatch for file" and found this https://lists.samba.org/archive/samba/2005-November/113886.html . Sure enough the test filename starts with a dot and hide dot files was set in the share:

Code:

[test_backup]
    path = /mnt/main/test_backup
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    vfs objects = zfs_space zfsacl aio_pthread streams_xattr
    hide dot files = yes
    guest ok = no
    nfs4:mode = special
    nfs4:acedup = merge
    nfs4:chown = true
    zfsacl:acesort = dontcare

I added "hide dot files = no" to the Auxiliary Parameters for the share and now it's WORKING!

Whew!

Chuck

Great. I'm glad you discovered a solution.