Interference between jail and afp share

[kb0]

I'm new to FreeNAS and have been struggling with erratic behavior with my Time Machine backups. I have been dropping AFP connections from my Mac to FreeNAS and these dropped connection can only be resolved by manually restarting the AFP service, reconnecting to the share and then running Time Machine. However, I can only run Time Machine once...if I try to rerun a backup my Mac complains that it cannot connect to the share. This behavior is repeatable.

I just discovered the source of my problem. At some point in time I created an instance of ownCloud from within a jail generated with the template: http://download.freenas.org/jails/9.3/x64/freenas-pluginjail-9.3-RELEASE.tgz. This is the only jail I currently run. It was created with VIMAGE and DHCP checked. The MAC address for the jail is fixed and the DHCP server assigns it a fixed IP address. If I turn this jail off, the problem I described above disappears; I sustain a connection to my share and have absolutely no problems with Time Machine backups whatsoever. As soon as I turn this jail on, the problem I described above returns immediately.

I would love to resolve this issue and get both ownCloud and Time Machine backups running contemporaneously. I am new to both FreeNAS/FreeBSD but can provide any information that might be helpful in debugging the problem. Just ask!

 

[MtK]

Interesting!
I'll dig into that tomorrow, might have a similar issue...

 

[Fraoch]

Bump...ever since I configured my first jail, I've had this issue. Time Machine backups worked automatically for months then suddenly it can't find the disk (even though Finder can connect to it just fine).

I believe I read on the forum that a recent FreeNAS update may have broken Time Machine compatibility so I'll have to experiment and see if it's the jail or not.

 

[danb35]

I can't speak to any possible interference between Owncloud and Time Machine (I'm running owncloud on a separate server), but I'm running FreeNAS-9.3-STABLE-201503270027 and Time Machine backups from two clients are running without issues. I am running several other jails, though, and they don't seem to be causing any problems.

 

[SweetAndLow]

Are you using the same dataset in the jail that time machine is using. You shouldn't do that if you are. Time machine is very specific in what it expects and doesn't play nice with others. So it should be a dataset all on its own and used for nothing other than a single time machine.

 

[Fraoch]

Are you using the same dataset in the jail that time machine is using. You shouldn't do that if you are. Time machine is very specific in what it expects and doesn't play nice with others. So it should be a dataset all on its own and used for nothing other than a single time machine.

I'll have to look into this. I believe there might be some overlap.

(Incidentally the jail isn't for ownCloud - I don't use the service.)

Did I mention how much I hate Time Machine? It's very very finnicky and there are no controls you can adjust to get things working. It either works or it doesn't.

 

[Robert Trevellyan]

Did I mention how much I hate Time Machine?

Have you tried Arq Backup? All it needs is an SFTP-capable destination.

 

[kb0]

New to FreeNAS. My volume is structured as follows:

> zpool.0
---> zpool.0
------> backups
--------- several people do time machine backups to this dataset
------> jails
--------- jails and jail templates appear here
------ various
------ sundry
------ datasets

Is this a problem?

 

[SweetAndLow]

each person doing a time machine backup should have their own dataset.

 

[kb0]

So weird. Turn off all jails and things work fine. Turn on any one of them and the AFP share is not found by any Mac.

Each person has a separate dataset inside of >backups. Each dataset is referred to by several separate shares owned by several different users.

 

[rogerh]

So weird. Turn off all jails and things work fine. Turn on any one of them and the AFP share is not found by any Mac.

Each person has a separate dataset inside of >backups. Each dataset is referred to by several separate shares owned by several different users.

Those last two sentences would seem to contradict each other. Ideally a dataset intended for Time Machine should only be shared using AFP, and should only be accessed by one user and one Mac. I use a unique user not used for any other purpose for each Time Machine share, and this also stops the Macs mounting the dataset in finder (only Time Machine is given the username and password) which may possibly be a good thing.

 

[kb0]

What I wrote is confusing. We have several people doing Time Machine backups and we want them to be somewhat secure, i.e. no user can modify another users' Time Machine backup. So there is a distinct dataset for each user and their TM backup. There is also a distinct share owned and writeable by each user which they mount on their Mac before doing a TM backup.

Is that any clearer??

 

[rogerh]

If the shares you are talking about are the shares of the datasets to be used for Time Machine backups, then it is neither necessary or (possibly) desirable to mount them in Finder first. I couldn't prove it is undesirable, but I reckon it is best to let nothing but Time Machine access them, in case they are being indexed or something while Time Machine wants to use them. (Have you noticed what happens when you type T M without the space in this forum?)

 

[kb0]

If a jail is running then Mac clients can neither mount the shares nor do T M backups to them. If we stop all jail instances, people can mount their shares and do T M backups...doesn't seem to matter too much if you mount before a backup or not.

As an aside: TM is formatted as "TM" for me on Chrome -- I don't see anything unusual. Is your client displaying it as a trademark symbol?

 

[rogerh]

If none of the ™ datasets is mounted on or shared by a jail, and none of their parent datasets are so affected by a jail then I think you have found a bug. (Yes a client issue - always catches me out - similar reasons why WebDAV is so messy.)

 

[kb0]

I wish it were a bug that everybody is experiencing! I don't mount any of the Time Machine datasets in any of the jails. I have been able to make this a repeatable phenomenon using several configurations, some of them were very very simple. I am turning off all jails until we can get both jails and Time Machine working. Kinda frustrating...

 

[Fraoch]

I wish it were a bug that everybody is experiencing! I don't mount any of the Time Machine datasets in any of the jails. I have been able to make this a repeatable phenomenon using several configurations, some of them were very very simple. I am turning of all jails until we can get both jails and Time Machine. Kinda frustrating...

Yes I can confirm I have the same issue. The storage attached to the jail is NOT the same dataset as the Time Machine dataset, shared by AFP. The Time Machine share is its own dataset - it is shared by AFP only, not using any other protocol. As soon as I stop the jail, it becomes available to Time Machine again. As soon as I start it, Time Machine can no longer see the share.

I'll file a bug shortly.

 

[rogerh]

And no-one is sharing (or mounting in the jail) the dataset (or the whole pool) in which the Time Machine datasets are found?

 

[Fraoch]

The whole volume is shared over NFS, but Time Machine worked perfectly until the jail was added.

I'll experiment with sharing only one separate dataset over NFS before submitting a bug.

 

[rogerh]

The whole volume is shared over NFS, but Time Machine worked perfectly until the jail was added.

I'll experiment with sharing only one separate dataset over NFS before submitting a bug.

I think that is a good idea. Also, if your jail needs storage mounted from your pool, I would set up a separate dataset (or perhaps the same one as your new NFS dataset if convenient) and mount that in the jail, rather then the whole pool (if that is what you have done). Anything else accessing the Time Machine share or its parent can annoy Time Machine.