D-Link Forums
The Graveyard - Products No Longer Supported => D-Link Storage => DNS-320 => Topic started by: baltzatu on January 12, 2012, 02:36:54 AM
-
Hello everybody.
Some time ago I bought a DNS-320 NAS. Since then, I have an issue regarding the user-defined network shares. Long story short, they keep disappearing; at first, they used to disappear only after a power outage, but yesterday they disappeared after three restarts. Upgrading the firmware to the latest version (2.02 - the original firmware was 2.00) and changing the HDD had no effect; the shares keep disappearing. Has anyone else encountered this problem or my unit is malfunctioning? I asked an official response, but it's been two weeks and I didn't receive one.
Also, in order to obtain some extra features, I installed Debian Squeeze on my NAS, using the package provided by D-Link and following the instructions by the letter. All seems well, excepting the fact that, no matter how I try, some packages I've installed (squid, qbittorrent-nox and miniDLNA) fail to start automatically after a restart. I tried to add them in the processes startup list using update-rc.d, I also tried adding them into rc.local... no avail (it seems that rc.local is not parsed at all, since it runs OK from the command line and it does what it's supposed to). I checked with sysv-rc-conf and everything looks OK. The annoying thing is that other packages (Apache2, MySql, pure-FTPD) do start without hiccups. Being a beginner in Debian, I would really appreciate a hand.
Thank you for your time/patience :) and have a nice day!
-
Hi,
Could you possibly post the link to all the instructions you followed please?
Regards
-
Hi, Padul.
I solved the boot run issue, thanks to SABnzbd Forums. All you have to do is place the commands you want to run at boot at the bottom of /boot/linuxrc. For me, it was like this:
/usr/sbin/squid -D -YC
/usr/sbin/minidlna start
/usr/bin/qbittorrent-nox start
Nobody has the same issue I do with network shares disapearance? They did it again today... it's getting downright annoying :(
-
Hi,
Sorry what i was referring to was which D-Link documentation you used to install Debian on the DNS-320. I am interested to read it, so if you could put the URL here I would really appreciate it.
All the best
-
Hi, Padul.
Here's the link: ftp://ftp.dlink.cz/dns/dns-320/driver_software/ (ftp://ftp.dlink.cz/dns/dns-320/driver_software/)
The How-To is inside the archive (DNS-320&325_linuxDebian_revA_Squeeze_all_en_20110111.zip).
Enjoy :)
-
Bine, mulţumesc
-
You're welcome.
-
Warning: long post :)
[Edit]
For RAID configurations, see RobR35 (http://forums.dlink.com/index.php?action=profile;u=68947)'s post (http://forums.dlink.com/index.php?topic=45382.msg215101#msg215101) below.
Okay... it's been a long time (this topic has not been posted in for at least 120 days :D), but I finally solved the "disappearance act". Maybe it'll help you.
So... every disk has a "hidden" dev, where the NAS keeps its config files. If you have one HDD, then it's /dev/sda4; if you have two, there's also a /dev/sdb4. I've mounted them as /mnt/HD/HD_a4 (and /mnt/HD/HD_b4, since I have two HDDs):
mount /dev/sdb2 /mnt/HD/HD_b2 # The second HDD - not necessary if you have only one hard disk
mount /dev/sda4 /mnt/HD/HD_a4
mount /dev/sdb4 /mnt/HD/HD_b4 # Not necessary if you have only one HDD
When you define a share, the information is written in /mnt/HD/HD_a4/.systemfile/.smb.xml (also in /mnt/HD/HD_b4/.systemfile/.smb.xml, if you have two HDDs). A share looks like this:
<item>
<volume_raid>1</volume_raid>
<hd_serial>0AA0AA00</hd_serial>
<name>SHARE</name>
<comment></comment>
<path>/mnt/HD/HD_b2/SHARE</path>
<browseable>yes</browseable>
<public>yes</public>
<oplocks>no</oplocks>
<map_archive>no</map_archive>
<read_list>#User1#</read_list>
<write_list>#User2#</write_list>
<invalid_users>#nobody#</invalid_users>
<recycle_enable>0</recycle_enable>
<recycle_tree>1</recycle_tree>
</item>
I don't know why, but something goes amok when you use FFP or Debian, and sometimes <hd_serial> messes up everything: for my Seagate HDD (serial number style: 0AA0AA00), everything is ok; for my WD HDD (serial number style: WD-WCAV00000000), everything goes down in flames.
When I use Debian Squeeze and I add a share on my WD using the web admin interface, the <hd_serial> value is null (empty):
<hd_serial></hd_serial>
Everything is ok... until the first restart, when the share goes AWOL: at first, it's not displayed in the web admin interface, but it can be accessed. The problem is if you create/modify/delete another share, because the one(s) that was/were not displayed disappear(s) completely. Why? Dunno, don't really care; the only thing I know is that the NAS adds the correct serial number inside .smb.xml file(s) at restart, and everything blows.
So... here's what I did:
0. Connect to NAS via ssh (puTTY), create the folders needed to mount the system dev(s) and alter /boot/linuxrc accordingly:
mkdir /mnt/HD/HD_b2 # The second HDD - not necessary if you have only one HDD
mkdir /mnt/HD/HD_a4
mkdir /mnt/HD/HD_b4 # Not necessary if you have only one HDD
nano /boot/linuxrc # Or vi, whatever editor you use
Add the following lines:
mount /dev/sdb2 /mnt/HD/HD_b2 # The second HDD - not necessary if you have only one HDD
mount /dev/sda4 /mnt/HD/HD_a4
mount /dev/sdb4 /mnt/HD/HD_b4 # Not necessary if you have only one HDD
1. Access the web admin interface and created a share on the "faulty" HDD.
2. Mount the system dev(s) and save the current share configuration(s):
mount /dev/sda4 /mnt/HD/HD_a4
mount /dev/sdb4 /mnt/HD/HD_b4 # Not necessary if you have only one HDD
cp /mnt/HD/HD_a4/.systemfile/.smb.xml /mnt/HD/HD_a2/a2.smb.xml
cp /mnt/HD/HD_b4/.systemfile/.smb.xml /mnt/HD/HD_a2/b2.smb.xml # Not necessary if you have only one HDD
3. Access the web admin interface and reboot the NAS, so it can put the faulty serial inside .smb.xml.
4. After restart, compare the new .smb.xml file(s) with a2.smb.xml (and b2.smb.xml, if you have two HDDs - they should be identical). You'll see the differences (the affected field is <hd_serial></hd_serial> only).
Here's how I fixed it: after detecting the "faulty" HDD serial number (mine was something like WD-WCAV00000000; yours might look different), I replaced it using sed (I added the lines at the bottom of /boot/linuxrc):
sed -i 's/WD-WCAV00000000//g' /mnt/HD/HD_a4/.systemfile/.smb.xml
sed -i 's/WD-WCAV00000000//g' /mnt/HD/HD_b4/.systemfile/.smb.xml
That's it. It took me almost two years, but hey... better late than never :D
-
Excellent! I just came across this exact problem myself.
Thanks for taking the time to write this all up.
I had to make an extra addition to linuxrc as my NAS is a DNS-320L using RAID1.
<volume_raid>1</volume_raid>
in /mnt/HD/HD_a4/.systemfile/.smb.xml was also being written on boot to:
<volume_raid>2</volume_raid>
an extra line in linuxrc:
sed -i 's@<volume_raid>2</volume_raid>@<volume_raid>1</volume_raid>@g' /mnt/HD/HD_a4/.systemfile/.smb.xml
fixed the problem. Thank you very much. :)
-
You're welcome. Glad I could help :)
-
Warning! Squeeze users only! FFP users should be fine if they have (or upgrade to) version 0.7.
Okay... forget what I've written.
The blasted thing messes up your network shares more than that: it deletes all the shares that are not the root and reside on the faulty serial number drive (everything that is "Volume_x/blah" gets the axe) and resets the access rights on that/those particular "Volume_x" to "<write_list>#nobody#,#@allaccount#</write_list>".
How and why on Earth have they thought about that... it's way over my limited intelligence. It's probably a partial shares reset, but it's still wrong (a word harsher than wrong would be in order, though).
Ergo, I've changed the approach. The way I've chosen this time is: define your shares, save the damn ".smb.xml" file, restore it if/whenever necessary.
IMPORTANT! Whenever you alter the shares, don't forget to delete the backup and run the script right after finishing the operation:
rm -f /etc/.Share.xml
/etc/share_fix.sh
So... here's round two:
0. Define all your shares via the web admin interface (via "Account Management" - "Network Shares");
1. SSH on your machine (PuTTY or whatever);
2. Prep the terrain for combat by eradicating the potential hostile:
rm -f /etc/.Share.xml
3. Put the backup/restore script in place:
3.1 nano /etc/share_fix.sh
3.2 Paste the content (it detects the second disk and disregard it if it's not installed):
#!/bin/bash
# Define the shares fix function
function sharefix {
# Mount the chosen disk system partition
echo "Mounting $1 in $2..."
mount "$1" "$2"
# Compare files and take action if necessary
echo "Comparing files..."
if diff $3 $4 >/dev/null ; then
echo "No changes found. No action taken."
else
echo "Changes found!"
diff $3 $4
echo "Restoring..."
cp $3 $4
fi
# Unmount disk system partition
echo "Dismounting $1 system partition..."
umount "$2"
}
# Variable init
Saved='/etc/.Share.xml'
TempPath='/tmp/.Temp'
SharesFile='/.systemfile/.smb.xml'
# Check temporary mount folder existence and create it if necessary
if [ ! -d "$TempPath" ] ; then
echo "Creating temporary mount folder..."
mkdir "$TempPath"
fi
# Check saved shares file existence. If it doesn't exist - create it and exit script
if [ ! -f "$Saved" ] ; then
# Mount the chosen disk system partition and create the saved shares file
echo "Saved shares file not found."
echo "Mounting first disk system partition in the temporary folder..."
mount /dev/sda4 "$TempPath"
# Create the saved shares file and change access privileges
echo "Creating saved shares file..."
cp "$TempPath$SharesFile" "$Saved"
# Unmount the chosen disk system partition, delete the temporary mount folder and exit script
echo "Dismounting $1..."
umount "$TempPath"
echo "Deleting temporary mount folder..."
rm -rf "$TempPath"
echo "Exiting script..."
exit
fi
# Init current shares file name
Current="$TempPath$SharesFile"
# Test second disk existence
SDE=$(blkid |grep "/dev/sdb4")
if [ -z "$SDE" ] ; then
echo "Second disk not inserted or not initialized. It will be ignored."
else
# Mount the system partition and check the shares
DEVICE="/dev/sdb4"
sharefix $DEVICE $TempPath $Saved $Current
fi
# Mount first disk's system partition and check the shares
DEVICE="/dev/sda4"
sharefix $DEVICE $TempPath $Saved $Current
# Delete temporary mount folder
echo "Deleting temporary mount folder..."
rm -rf "$TempPath"
echo "Script completed. Exiting..."
exit
3.3 Make it executable and run it, to create the backup:
chmod o+x /etc/share_fix.sh
/etc/share_fix.sh
4. (Optional) Put the script in /boot/linuxrc (in order to be executed on system startup - not that failsafe - if you reboot the system, but forget to replace the backup, the old one will be restored; on the other hand, if you do that, your "sick" shares will get the axe, so... better not forget):
nano /boot/linuxrc
Add the following line and remove the sed/mount commands described in my last long post:
/etc/share_fix.sh
The end (hopefully).
P.S.: I repeat: FFP users are lucky. With version 0.7 there's no problem with the shares. If you do have problems, just upgrade your FFP. So, the nonsense above is for Squeeze unfortunates only :)
-
Warning! Squeeze users only! FFP users should be fine if they have (or upgrade to) version 0.7.
Okay... forget what I've written.
The blasted thing messes up your network shares more than that: it deletes all the shares that are not the root and reside on the faulty serial number drive (everything that is "Volume_x/blah" gets the axe) and resets the access rights on that/those particular "Volume_x" to "<write_list>#nobody#,#@allaccount#</write_list>".
How and why on Earth have they thought about that... it's way over my limited intelligence. It's probably a partial shares reset, but it's still wrong (a word harsher than wrong would be in order, though).
Ergo, I've changed the approach. The way I've chosen this time is: define your shares, save the damn ".smb.xml" file, restore it if/whenever necessary.
IMPORTANT! Whenever you alter the shares, don't forget to delete the backup and run the script right after finishing the operation:
rm -f /etc/.Share.xml
/etc/share_fix.sh
So... here's round two:
0. Define all your shares via the web admin interface (via "Account Management" - "Network Shares");
1. SSH on your machine (PuTTY or whatever);
2. Prep the terrain for combat by eradicating the potential hostile:
rm -f /etc/.Share.xml
3. Put the backup/restore script in place:
3.1 nano /etc/share_fix.sh
3.2 Paste the content (it detects the second disk and disregard it if it's not installed):
#!/bin/bash
# Define the shares fix function
function sharefix {
# Mount the chosen disk system partition
echo "Mounting $1 in $2..."
mount "$1" "$2"
# Compare files and take action if necessary
echo "Comparing files..."
if diff $3 $4 >/dev/null ; then
echo "No changes found. No action taken."
else
echo "Changes found!"
diff $3 $4
echo "Restoring..."
cp $3 $4
fi
# Unmount disk system partition
echo "Dismounting $1 system partition..."
umount "$2"
}
# Variable init
Saved='/etc/.Share.xml'
TempPath='/tmp/.Temp'
SharesFile='/.systemfile/.smb.xml'
# Check temporary mount folder existence and create it if necessary
if [ ! -d "$TempPath" ] ; then
echo "Creating temporary mount folder..."
mkdir "$TempPath"
fi
# Check saved shares file existence. If it doesn't exist - create it and exit script
if [ ! -f "$Saved" ] ; then
# Mount the chosen disk system partition and create the saved shares file
echo "Saved shares file not found."
echo "Mounting first disk system partition in the temporary folder..."
mount /dev/sda4 "$TempPath"
# Create the saved shares file and change access privileges
echo "Creating saved shares file..."
cp "$TempPath$SharesFile" "$Saved"
# Unmount the chosen disk system partition, delete the temporary mount folder and exit script
echo "Dismounting $1..."
umount "$TempPath"
echo "Deleting temporary mount folder..."
rm -rf "$TempPath"
echo "Exiting script..."
exit
fi
# Init current shares file name
Current="$TempPath$SharesFile"
# Test second disk existence
SDE=$(blkid |grep "/dev/sdb4")
if [ -z "$SDE" ] ; then
echo "Second disk not inserted or not initialized. It will be ignored."
else
# Mount the system partition and check the shares
DEVICE="/dev/sdb4"
sharefix $DEVICE $TempPath $Saved $Current
fi
# Mount first disk's system partition and check the shares
DEVICE="/dev/sda4"
sharefix $DEVICE $TempPath $Saved $Current
# Delete temporary mount folder
echo "Deleting temporary mount folder..."
rm -rf "$TempPath"
echo "Script completed. Exiting..."
exit
3.3 Make it executable and run it, to create the backup:
chmod o+x /etc/share_fix.sh
/etc/share_fix.sh
4. (Optional) Put the script in /boot/linuxrc (in order to be executed on system startup - not that failsafe - if you reboot the system, but forget to replace the backup, the old one will be restored; on the other hand, if you do that, your "sick" shares will get the axe, so... better not forget):
nano /boot/linuxrc
Add the following line and remove the sed/mount commands described in my last long post:
/etc/share_fix.sh
The end (hopefully).
P.S.: I repeat: FFP users are lucky. With version 0.7 there's no problem with the shares. If you do have problems, just upgrade your FFP. So, the nonsense above is for Squeeze unfortunates only :)
baltzatu, I registered just to say thank you!!! You have fixed the exact problem I was having. Awesome!
-
You're welcome, Tiago. Glad I could help :)
-
Hello !
First of all, thank to you, baltzatu, for your great work. I had the problem with the network shares with my Debian Squeeze (on my DNS-325), and you saved my configuration ;)
The DNS-325 has the same issue, and the restoring of the .smb.xml solved the problem. But, you have also a smb.conf (in a "strange" directory /mnt/root/etc/samba).
So, I adapt the code (thank again for this) to restore also the smb.conf. And, to continue the work of baltzatu, I write a share_backup script, which keeps a backups of the files (with a date) : We never know !!!!!!
1. the Share_backup script
#!/bin/bash
# Variable init
DATE=`date "+%F_%T"`
SavedShare='/var/backups/ShareDirectory.smb.xml'
TempPath='/tmp/.Temp'
SharesFile='/.systemfile/.smb.xml'
SmbFile='/mnt/root/etc/samba/smb.conf'
SavedSmb='/var/backups/Saved.smb.conf'
# Check temporary mount folder existence and create it if necessary
if [ ! -d "$TempPath" ] ; then
echo "Creating temporary mount folder..."
mkdir "$TempPath"
fi
# Check the existence of Saved Share file and Saved smb.conf and Backup them - if necessary
if [ -f "$SavedShare" ] ; then
echo "Backup of Saved Share files"
cp "$SavedShare" "$SavedShare-$DATE"
fi
if [ -f "$SavedSmb" ] ; then
echo "Backup of smb.conf file"
cp "$SavedSmb" "$SavedSmb-$DATE"
fi
# Updated the smb.conf file
echo "Creating smb.conf backup file"
cp "$SmbFile" "$SavedSmb"
# Mount the chosen disk system partition and update the saved shares file
echo "Mounting first disk system partition in the temporary folder..."
mount /dev/sda4 "$TempPath"
echo "Creating saved shares file..."
cp "$TempPath$SharesFile" "$SavedShare"
# Unmount the chosen disk system partition, delete the temporary mount folder and exit script
echo "Dismounting $1..."
umount "$TempPath"
echo "Deleting temporary mount folder..."
rm -rf "$TempPath"
echo "Exiting script..."
exit
2. The share Restore script (adapt to my DNS-325 configuration)
#!/bin/bash
# Define the shares fix function
function sharefix {
# Mount the chosen disk system partition
echo "Mounting $1 in $2..."
mount "$1" "$2"
# Compare files and take action if necessary
echo "Comparing files..."
if diff $3 $4 >/dev/null ; then
echo "No changes found. No action taken."
else
echo "Changes found : "
diff $3 $4
echo "Restoring..."
cp $3 $4
fi
# Unmount disk system partition
echo "Dismounting $1 system partition..."
umount "$2"
}
function smbfix {
# Compare files and take action if necessary
echo "Comparing files..."
if diff $1 $2 >/dev/null ; then
echo "No changes found. No action taken."
else
echo "Changes found : "
diff $1 $2
echo "Restoring..."
cp $1 $2
fi
}
# Variable init
SavedShare='/var/backups/ShareDirectory.smb.xml'
TempPath='/tmp/.Temp'
SharesFile='/.systemfile/.smb.xml'
SavedSmb='/var/backups/Saved.smb.conf'
SmbFile='/mnt/root/etc/samba/smb.conf'
# Check temporary mount folder existence and create it if necessary
if [ ! -d "$TempPath" ] ; then
echo "Creating temporary mount folder..."
mkdir "$TempPath"
fi
# Check saved shares file existence. If it doesn't exist - create it and exit script
if [ ! -f "$SavedShare" ] ; then
# Mount the chosen disk system partition and create the saved shares file
echo "Saved shares file not found."
echo "Mounting first disk system partition in the temporary folder..."
mount /dev/sda4 "$TempPath"
# Create the saved shares file and change access privileges
echo "Creating saved shares file..."
cp "$TempPath$SharesFile" "$SavedShare"
# Unmount the chosen disk system partition, delete the temporary mount folder and exit script
echo "Dismounting $1..."
umount "$TempPath"
echo "Deleting temporary mount folder..."
rm -rf "$TempPath"
echo "Exiting script..."
exit
fi
# Init current shares file name
Current="$TempPath$SharesFile"
# Mount first disk's system partition and check the shares
DEVICE="/dev/sda4"
sharefix $DEVICE $TempPath $SavedShare $Current
# Test second disk existence (in my case, not necessary : 2 disks in RAID1)
#SDE=$(blkid |grep "/dev/sdb4")
#if [ -z "$SDE" ] ; then
# echo "Second disk not inserted or not initialized. It will be ignored."
#else
# Mount the second's system partition and check the shares
DEVICE="/dev/sdb4"
sharefix $DEVICE $TempPath $SavedShare $Current
#fi
# Check the smb.conf file
smbfix $SavedSmb $SmbFile
# Delete temporary mount folder
echo "Deleting temporary mount folder..."
rm -rf "$TempPath"
echo "Script completed. Exiting..."
exit
The end :D
-
Hello, Dams_NaZ.
Glad I could help. Too bad D-Link didn't solve it, but hey... can't have them all, right? :D
-
Hello Balzatu !
Sure that a correction from D-Link should have been a good thing !!!
I reached my limit in Linux... Wait and see !!! Perhaps, an expert will find the solution to avoid the modification of the smb.xml after reboot ;)
Thank again for your amazing work !
-
Hey, Dams_NaZ.
My Linux knowledge is pretty basic (worse, even), but I took the problem, studied it and found a solution. Where there's a will, there's a way.
It would be nice if D-Link will fix it. I highly doubt it, though. As long as the device works properly (well... sort of) with their firmware, they won't do a thing. Sadly, D-Link support is plain awful. I closed my own support request after one year, just because no one even considered it. And a simple "No, it's not possible" would've been an acceptable (and somehow correct) answer.
You're welcome :)