Extended attributes reappear when reconnecting external drive
The cause of the problem—or, rather, the cause of the symptoms of the problem—is indeed explained by learning the content of the extended attribute com.apple.FinderInfo. It reveals that the Finder has set the file’s file type and creator respectively to brok and MACS, signifying the file is engaged in the process of being copied and therefore cannot be accessed. (These flags are supposed to be erased upon completion of the copying process.) As a consequence, the Finder "greys out" the icons of such files to reflect their status of immutability by the user. Erasing the com.apple.FinderInfo extended attribute relieves the situation by removing the proximate cause.

The real problem, however, is the constant reassignment of this "busy being copied" status to the various files. Indeed, you specifically asked why the extended attributes reappear for particular files. My answer: I don’t know the mechanics of the events, but I do know what’s behind it.

Apple natively supports reading, but not writing, to NTFS drives. The bespoke fstab workaround method you are currently using to permit writing to the disk is known to be unstable, and is guaranteed to cause problems. (Is your username really username?) I wondered how it was you came to the abstruse idea of erasing extended attributes to correct the inaccessible file situation, and a visit to the Mounty Software site (the source of your previous workaround) showed me it was their specific recommendation. As you have learned, it is not a lasting solution. The problem will continue as long as you continue to use your current method of NTFS filesystem access.

If you must have read/write access to an NTFS formatted drive—and cannot replace it with one in the natively supported exFAT format—you will have to choose a third party offering to provide a permanent solution. Those I know of which offer acceptable usability are Tuxera, Paragon, and Fuse/NTFS3G. The first two are commercial products available on a free-trial basis; the third is a combination of two open source products.


  EDIT: Response to OP's comment below


I’m sorry to say I don’t have any command line instructions which would definitely help you. I believe that the only way to fix the problem is to change the method you use for filesystem access from one which is known to have issues, as your current method does, to one which does not.

That said, I offer the following purely as an experiment, as I have no way to test it. We know that the benefit of erasing the extended attributes of the affected files only lasts until the next time the drive is mounted. It is possible that assigning a dummy value to a file’s com.apple.FinderInfo attribute will allow it to persist unmolested through the mounting process and prevent the Finder from re-assigning brok/MACS status. Specifically, this command will give a bogus file type of hack to &lt;targetfile.ext&gt;.  Test it on just one or two of your problem files, and see what happens to them when the drive is unmounted / remounted.

xattr -wx com.apple.FinderInfo 6861636B00000000000000000000000000000000000000000000000000000000 &lt;targetfile.ext&gt;

(Why all the zeroes? The com.apple.FinderInfo extended attribute must be written as a single 32-byte block. Anyway, whatever it may look like here, it's one command, all on one line as you'd expect.)