_un Files Everywhere

Hi all, I’ve been noticing this for quite some time now, but there seem to be a bunch of files with filename _un peppered throughout the NAS. The files are small and usually only contain a single long string of numbers. The numbers in each file are different. Any ideas what could be creating these and where they come from and what they do? I’ve deleted them, but they come back. Any thoughts?

EDIT: I just ssh’d in to the NAS to see who owns the file, and the files are created by root:root - which means this is some kind of system process since all the files that are saved from my user login all show [username]:share so I’d really love some insight into this. I’m not currently running any extra applications on the NAS, since this is a Gen1 Mirror and they don’t work so great.

1 Like

Hi shayaknyc,

Maybe you should try contacting WD’s Technical Support about this.

To Contact WD for Technical Support

The link below will allow you to call support.

Hello shayaknyc,

did you figure out what these are and why they’re created? Wouldn’t mind if they’d just be invisible, but they’re not.

Have a nice day

I have a single “_un” file at the top-level of one of my shares on a PR4100 which is constantly being re-created with an ever-growing number in it. Currently it is a 9-digit number but it is growing fast.

I am presently running rsync on this NAS, copying data from it to another NAS. When I stop the rsync process, the _un file stops being recreated, and when I start rsync again the _un file is again recreated with the ever-growing number in it. To be clear, this is on the NAS where rsync is reading from. Also I tried running “while true; lsof -n|grep _un$; echo -n .; done” and I never see any processes with the file open.

I’d really like to know what is writing this file, and why!

# while true; do now="$(cat /mnt/HD/HD_a2/sharename/_un)"; if [ "$last" != "$now" ]; then last="$now"; echo "$(date) $now"; fi; sleep 1; done
Fri Nov  8 17:07:57 CET 2019 505292180
Fri Nov  8 17:08:02 CET 2019 515019982
Fri Nov  8 17:08:04 CET 2019 524752424
Fri Nov  8 17:08:09 CET 2019 534506774
Fri Nov  8 17:08:14 CET 2019 544202896
Fri Nov  8 17:08:17 CET 2019 553973996
Fri Nov  8 17:08:19 CET 2019 563700146
Fri Nov  8 17:08:27 CET 2019 573456630
Fri Nov  8 17:08:45 CET 2019 583157864
Fri Nov  8 17:09:02 CET 2019 592857292
Fri Nov  8 17:09:25 CET 2019 602555326
Fri Nov  8 17:09:45 CET 2019 612299136
Fri Nov  8 17:10:00 CET 2019 622021420
Fri Nov  8 17:10:18 CET 2019 631706882


On my MyCloud EX2 Ultra I also noticed that the “_un” file will be (re)created if you run a rsync command with SSH. The “_un” file seems to be only created to the target base directory.

It seems that the “_un” files only get created if you download something on your own system, not if you upload. Example: rsync user@remotehost:/xyz /mnt/....../backup will create an “_un” file
while rsync /mnt/....../backup user@remotehost:/xyz will not.

On my MyCloud EX2 Ultra, rsync is located at /usr/sbin/rsync and reports to be rsync version 3.0.7.
The binary contains the string “%s_un”, which is not part of the source code of RSync 3.0.7.

I compared the strings of the version 3.0.7 rsync binary of the WD EX2 Ultra and the version 3.0.7 rsync binary that I compiled on a RaspberryPi with the configuration setting --disable-debug. Here is the diff of the relevant section:

So, you can see, the files “…_un” and “…_lock” are likely to be created at some stage of program execution. (where “…” can be “empty”, of course).

The “…_lock” file as well as the error message “rsnap: open error for lock file” seems to belong to some kind of integration of rsnap.

I am very sure that the creation of the “_un” file is part of a custom debug code that has been forgotten. This should actually be reported as bug!

I hope this analysis helps to improve the product. It also made me feel comfortable, because now I know that this mystery file is harmless and no virus or file system corruption etc.