WOAH! What's happened here!?

I was not awake at 5:39am!

-rw-r--r-- 1 root root 63 Nov 14 05:39 2
drwxrwxrwx 11 root root 65536 Dec 8 00:16 CacheVolume
drwxr-xr-x 7 root root 65536 Oct 26 17:37 DataVolume
-rw-r--r-- 1 root root 0 Nov 14 05:39 alias.inc
-rw-r--r-- 1 root root 0 Nov 14 05:39 apache_userlist
drwxr-xr-x 2 root root 4096 Nov 14 05:39 bin
drwxr-xr-x 3 root root 4096 Nov 18 01:34 boot
drwxr-xr-x 2 root root 4096 Nov 14 05:34 debootstrap
drwxr-xr-x 10 root root 2480 Dec 15 12:02 dev
drwxr-xr-x 80 root root 4096 Dec 15 06:11 etc
drwxr-xr-x 3 root root 4096 Nov 14 05:34 home
-rw-r--r-- 1 root root 0 Nov 14 05:39 htgroup
drwxr-xr-x 10 root root 4096 Nov 14 05:39 lib
drwx------ 2 root root 16384 Nov 14 05:40 lost+found
drwxr-xr-x 3 root root 4096 Dec 13 23:11 media
drwxr-xr-x 20 root share 65536 Oct 12 13:06 nfs
drwxr-xr-x 2 root root 4096 Nov 14 05:34 opt
dr-xr-xr-x 88 root root 0 Jan 1 1970 proc
-rw-r--r-- 1 root root 0 Nov 14 05:39 require.inc
drwxr-xr-x 5 root root 4096 Dec 14 00:12 root
drwxr-xr-x 2 root root 4096 Nov 14 05:39 sbin
drwxr-xr-x 2 root root 4096 Nov 14 05:34 selinux
drwxr-xr-x 20 root share 65536 Oct 12 13:06 shares
drwxr-xr-x 2 root root 4096 Nov 14 05:34 srv
drwxr-xr-x 12 root root 0 Jan 1 1970 sys
drwxrwxrwt 10 root root 1260 Dec 15 13:05 tmp
drwxr-xr-x 14 root root 4096 Nov 14 05:40 usr
drwxr-xr-x 12 root root 4096 Nov 14 05:40 var

 Where has the file 2 appeared from? Contents =

//etc/nasglobalconfig.ini: line 1: [global]: command not found

Also, from where has alias.inc , apache_userlist , htgroup and require.inc appeared from. All of which are zero bytes long.

I repeat.  I was very well fast asleep at 5:39am so no way was I pushing aby buttons on any computer.

I checked against telnet sessions logs I keep and those files are NOT supposed to be at the root of the file system. So, the question now is what other changes may have happened? So far the Dashboard UI on my NAS is not bricked.

File mtimes are preserved in archives.  So, I’m assuming, that these file times were put there by the update process installing files from the update.

I can’t get to my MBL right now, but have you tried to “stat” the files?  You’ll get full inode information.

Like this:

# stat /etc/group
  File: `/etc/group'
  Size: 1151 Blocks: 8 IO Block: 4096 regular file
Device: 805h/2053d	Inode: 1521209 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2011-12-15 05:25:01.000000000 -0500
Modify: 2011-10-14 15:49:08.000000000 -0400
Change: 2011-10-14 15:49:08.000000000 -0400

Unix files have three times, Access, Modify, and Change.  “ls -l” shows the Modify time, also known as the mtime, and mtimes older than 6 months are shown only as dates by “ls -l”.

The Unix “touch” command can change any of these, but not all three at the same time.

Access time is the last time the file handle was opened or closed.  Modify is that last time the contents or metatdata were changed.  Change is the last time the metadata was changed. (either chmod or chown or any changes in the inode)

The “2” file looks like it’s due to a scripting error.  The shell operates with three streams, STDIN, STDOUT, and STDERR.  A good example to demonstrate this is via the “fuser” command which mixes STDOUT with STDERR on the screen.  fuser lists the process id’s that have a file handle open.

The first command below shows the normal output of fuser against a file I happen to know has open filehandles.  The pids are actually on STDOUT, and the rest is on STDERR.  So, I can redirect STDOUT to dev null, as shown in the second command, to demonstrate that what’s going to the screen is STDERR.

 The next command shows how to redirect STDOUT to STDERR, which all shows up on the screen.  Now, if you leave out the ampersand, that’s a typo, which creates a file called “2” containing the STDOUT output.

# fuser /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache: 867m 871m 945m 1124m 1133m 1288m 1344m 1481m 1513m 1532m 2114m 2123m 2186m 2195m 2201m 2210m 2217m 2219m 2224m 2226m 2236m 2246m 2248m 2250m 2252m 2253m 2261m 2263m 2272m 2281m 2286m 2290m 2303m 2305m 2307m 2321m 2325m 2339m 2346m 2351m 2353m 2355m 2378m 2385m 2394m 2398m 2401m 2418m 2428m 2430m 2472m 2552m 2555m 2580m 2609m 2670m 12374m 12380m 12667m 15210m 15277m 16668m 17166m 17278m 17648m 17798m 17807m 17810m
# fuser /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache > /dev/null
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache:mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
# fuser /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache 1>&2
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache: 867m 871m 945m 1124m 1133m 1288m 1344m 1481m 1513m 1532m 2114m 2123m 2186m 2195m 2201m 2210m 2217m 2219m 2224m 2226m 2236m 2246m 2248m 2250m 2252m 2253m 2261m 2263m 2272m 2281m 2286m 2290m 2303m 2305m 2307m 2321m 2325m 2339m 2346m 2351m 2353m 2355m 2378m 2385m 2394m 2398m 2401m 2418m 2428m 2430m 2472m 2552m 2555m 2580m 2609m 2670m 12374m 12380m 12667m 15210m 15277m 16668m 17166m 17278m 17648m 17798m 17807m 17810m

# fuser /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache 1>2
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache:mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
# ls -l 2
-rw-r--r-- 1 root root 408 2011-12-15 12:04 2
# more 2
   867 871 945 1124 1133 1288 1344 1481 1513 1532 2114 2123 2186 2195  
2201 2210 2217 2219 2224 2226 2236 2246 2248 2250 2252 2253 2261 2263 22
72 2281 2286 2290 2303 2305 2307 2321 2325 2339 2346 2351 2353 2355 2378
  2385 2394 2398 2401 2418 2428 2430 2472 2552 2555 2580 2609 2670 12374 1
2380 12667 15210 15277 16668 17166 17278 17648 17798 17807 17810

Likely nothing nefarious is happening.

M.

Point of note. I do not have automatic firmware updates enabled on my MBL. It was supposed to be doing nothing at that time of day. Just it’s usual background tasks.

There have been a lot of reports of drive’s being bricked and the Dashboard UI being bricked. I wonder if I’ve seen a viable reason for these failures. Some script has a bug and under certain conditions will screw-up files.

The files plonked in the root of the file system were to do with the Apache2 web server.  If the likes of htaccess and other related files get blanked or corrupted then of course the  Apache2 web server will malfunction as well as the MBL’s Dashboard UI.

Also, why was some script trying to execute /etc/nasglobalconfig.ini when it’s clearly NOT a script!

[global]
SHARES_PATH="/shares"
BACKUPS_PATH="/DataVolume/backup"
SOFTWARE_PATH="/shares/Public/Software"
WDCOMP_DIR="/etc/wdcomp.d"
SETTINGS_DIR_NAME="saved_settings"
RESTORE_SETTINGS_FROM_DIR_TRIGGER=/etc/.restoreSettingsFromDir
VERSION_FILE="/etc/version"
SYSTEM_CONF_FILE_NAME="system.conf"
SYSTEM_CONF_FILE="/etc/${SYSTEM_CONF_FILE_NAME}"
SSH_LOGIN_TRIGGER="/etc/.sshlogin"
SSH_LOGIN_DESCRIPTION_STRING="SSH LOGIN"
SSH_LOGIN_VERSION="00.00.00"
INIT_DB_TOUCHFILE="/etc/nas/.initialize_db"
[wd-nas]
smbConfig=/etc/samba/smb.conf
trusteesConfig=/etc/trustees.conf


[admin]
WIPE_STATUS_FILE="/tmp/wipe-status"
DATA_VOLUME="/DataVolume"
READY_FILE="/tmp/ready"
TEMPERATURE_STATUS_FILE="/tmp/overtemp"
SMART_STATUS_FILE="/tmp/smart_fail"
FREESPACE_STATUS_FILE="/tmp/freespace_failed"
VOLUME_STATUS_FILE="/tmp/volume_failed"
NAS_DEVICE_INFO_FILE="/etc/nas/nasdevice.xml"
LANGUAGE_FILE="/etc/language.conf"
HDD_STANDBY_FILE="/etc/standby.conf"
AUTO_UPDATE_FILE="/etc/auto_update.conf"
SH_SETUP_PARAM_FILE="/usr/local/sbin/share-param.sh"
NTPDATE_FILE="/etc/nas/service_startup/ntpdate"
TIMEZONE_FILE="/etc/timezone"
PASSWD_FILE="/etc/passwd"
SHADOW_FILE="/etc/shadow"
VERSION_BUILDTIME_FILE="/etc/version.buildtime"
VERSION_UPDATE_FILE="/etc/version.update"
UPGRADE_LINK="/tmp/dev_fw_upgrade_link"
UPGRADE_INFO="/tmp/fw_upgrade_info"
VIDEO_SIZE_FILE="/var/local/nas_file_tally/video_size"
PHOTO_SIZE_FILE="/var/local/nas_file_tally/photos_size"
MUSIC_SIZE_FILE="/var/local/nas_file_tally/music_size"
SHARE_NAME_FILE="/etc/trustees.conf"
[networking]
hostsConfig=/etc/hosts
networkConfig=/etc/network/interfaces
dnsConfig=/etc/resolv.conf
dhclientConfig=/etc/dhcp3/dhclient.conf
hostnameFile=/etc/hostname

I agree these remnants are a result of scripting errors.

The leading double slash in your “2” file is also a common tell of pathname expansion with variables. 

You only have the one line in  your “2” file.  You should have one for every [stanza]  meaning  that the shell was called with the “-e” option, something a startup script might do.

And since “/etc/nasglobalconfig.ini” is not executable, something like this would have to have happened:

$ sh -e /$PWD/junk
//home/mario/junk: 1: [global]: not found

When did these files appear on your MBL?  Could they have been shipped with a fix?  Is the clock on the MBL correct?

It is strange that the month shown is November. The clock on my MBL is correct and as far as I can tell has never been wrong and the date on my MBL is correct now.

I really am sure the files indicated below were not present in the root of the NAS’s OS’s file system. I’ve since removed them.