Unable to complete rsync tasks when acrolock*.tmp files are present on Core 13.0-U3

[testfire10]

I have this issue where editing/commenting a pdf file generates an 'acrolock' file. for example: acrolock17528.7.3535847644.tmp. This happens every time I save an edited pdf. When TrueNAS Core encounters this file during my normal rsync tasks backing up to a remote server, the rsync task fails, every time. I have to manually remove the acrolock file, and after doing this, the rsync task will run. I came across an old issue (that I cannot view) which seems to be reporting the same problem (see below). Should I be reporting this again? Does anyone else have this issue? Seems like it would be much more common that what my searches seem to indicate.

I'm not sure what streams_xattr means either - is this something that I can disable?

[NAS-107999] - Adobe reader pollutes SMB shares with undeletable acrolock<timestamp>.tmp files when streams_xattr is enabled

 

[winnielinnie]

I'm not sure what streams_xattr means either - is this something that I can disable?

Yes. You can disable "Alternate Data Streams" in the SMB share's configuration.

If you don't think you're using them, then you're probably not using them.

 

[testfire10]

Yes. You can disable "Alternate Data Streams" in the SMB share's configuration.

If you don't think you're using them, then you're probably not using them.

Thanks @winnielinnie. Can you elaborate on what the Alternate Data Streams function does? I'd like to understand that better before I disable it.

 

[Samuel Tai]

Can you elaborate on what the Alternate Data Streams function does?

Click the ? next to it for an explanation. It's basically for Mac SMB support.

Enable Alternate Data Streams

Select to allow multiple NTFS data streams. Disabling this option causes MacOS to write streams to files on the file system.

 

[testfire10]

Click the ? next to it for an explanation. It's basically for Mac SMB support.

Enable Alternate Data Streams

Select to allow multiple NTFS data streams. Disabling this option causes MacOS to write streams to files on the file system.

I took a look at the link in the '?'. I do happen to have a couple of apple devices that require access to the share. I suppose I can just try it and see what happens.

 

[winnielinnie]

Can you elaborate on what the Alternate Data Streams function does? I'd like to understand that better before I disable it.

To this day, I still don't quite fully grasp it, nor do I see any practical benefits for home users.

With NTFS and macOS, a file can have more than one "data stream". (In Apple language, they're called "forks", I believe.) In order to view this "hidden" data, you either need software that is aware of it, or you need to actively look for it in the command-line. This applies to Windows and macOS; not Linux nor FreeBSD (POSIX).

So you might have a file named "notes.txt"

Its contents (the main "data stream") are:

Code:

This is a boring note to remind myself I am a boring person.

But there's also an alternate ("hidden") data stream in this file called "secret". With NTFS, it's accessed via the syntax "notes.txt:secret".

Its contents (this "hidden stream") are:

Code:

I am a cool person!

If you open up "notes.txt" with any text editor, you won't see any of the "hidden stream" data. You need to specify you want to access the alternate data stream instead, by invoking "notes.txt:secret"


Because ZFS doesn't truly support alternate data streams, it can piggy-back off of "xattrs" (extended attributes) to "emulate" them. The file "notes.txt" will be saved, like normal, without any hidden stream (since this is impossible with ZFS). But it will apply an "xattr" in the namespace "user.DosStream", in which this data is saved. Therefor, if you use a tool to read a file's xattr, you will see user.DosStream as an extended attribute, with the value of "I am a cool person!"

I have no clue if there's a size limitation to this (ADS over an SMB share). I never tried to test any size limits. Nor do I find it practical to have large amounts of xattrs.


If you disable ADS support on your SMB share, then any files with such "alternate streams" will lose this "hidden" data upon being saved to the SMB share. (Then there's the exception for macOS, in which such a "fork data stream" will be saved as a new companion file in the same directory.)

 

[testfire10]

To this day, I still don't quite fully grasp it, nor do I see any practical benefits for home users.

With NTFS and macOS, a file can have more than one "data stream". (In Apple language, they're called "forks", I believe.) In order to view this "hidden" data, you either need software that is aware of it, or you need to actively look for it in the command-line. This applies to Windows and macOS; not Linux nor FreeBSD (POSIX).

So you might have a file named "notes.txt"

Its contents (the main "data stream") are:

Code:

This is a boring note to remind myself I am a boring person.

But there's also an alternate ("hidden") data stream in this file called "secret". With NTFS, it's accessed via the syntax "notes.txt:secret".

Its contents (this "hidden stream") are:

Code:

I am a cool person!

If you open up "notes.txt" with any text editor, you won't see any of the "hidden stream" data. You need to specify you want to access the alternate data stream instead, by invoking "notes.txt:secret"


Because ZFS doesn't truly support alternate data streams, it can piggy-back off of "xattrs" (extended attributes) to "emulate" them. The file "notes.txt" will be saved, like normal, without any hidden stream (since this is impossible with ZFS). But it will apply an "xattr" in the namespace "user.DosStream", in which this data is saved. Therefor, if you use a tool to read a file's xattr, you will see user.DosStream as an extended attribute, with the value of "I am a cool person!"

I have no clue if there's a size limitation to this (ADS over an SMB share). I never tried to test any size limits. Nor do I find it practical to have large amounts of xattrs.


If you disable ADS support on your SMB share, then any files with such "alternate streams" will lose this "hidden" data up-on being saved to the SMB share. (Then there's the exception for macOS, in which such a "fork data stream" will be saved as a new companion file in the same directory.

This was very helpful, thank you for explaining. I'm going to disable it and see if I get any unintended consequences.

 

[testfire10]

Actually, it seems I cannot (in the GUI at least) change this setting. Do I have to create a new share in order to do this?

 

[winnielinnie]

Don't use a preset for the share.

Under "Purpose", select "No preset". This will unlock all options.

 

[winnielinnie]

You might also find this useful:

Acrobat creating acrolock#######.tmp files?

I had a user the other day who was having issues saving PDF files using Acrobat. What they were trying to do was simply open the PDF file in question, make a simple change, and save the file back a...

superuser.com

Alternate Data Streams might be a red herring.

 

[testfire10]

You might also find this useful:

Acrobat creating acrolock#######.tmp files?

I had a user the other day who was having issues saving PDF files using Acrobat. What they were trying to do was simply open the PDF file in question, make a simple change, and save the file back a...

superuser.com

Alternate Data Streams might be a red herring.

You know, I think now I remember finding this article a while back (I first noticed this issue a year ago, and didn't have the time to deal with it).

I did some testing. Changing the Alternate Data Streams setting seemed to have no effect. Changing the setting in Adobe Reader described in your superuser link fixed the issue.

Although, now there is kind of a weird thing I have not noticed; when I open a pdf, edit it, and save it, the first several times I try to save the file, Adobe tells me the file is read only. After several attempts to save over the course of several seconds, it finally starts working at some point. Seems to do this consistently with files in different locations on the share. It's like it takes 30s or so for the file to be 'checked out' or given read/write access to the user that opened it. Weird.

Any way, thank you for your help and information.