Kitz Forum
Computer Software => Linux => Topic started by: sheddyian on January 14, 2014, 06:58:03 PM
-
Summary : Previously working samba shares now give an error "the network path was not found" when attempting access from Windows. The shares exist, and can be seen, but cannot be accessed.
Setting aside the problems I'm having getting idle drives to spin down, I'm carrying on setting up the Raspberry pi disk server (NAS).
The other day it all went smoothly, I connected a disk via a USB adaptor, created a partition, formatted it (ext4) and shared it out via samba.
Windows PCs could see the share, and access it, both read and write, without having to give a username or password. This is exactly what I wanted.
Yesterday I took the hard disk out of my existing slow standalone NAS unit, connected it to a 2nd USB adaptor on the pi, and discovered it was formatted by the NAS with the XFS file system.
To avoid confusion, I dismounted the 1st disk (named vol0) and mounted the XFS disk. I shared this out out the network, and copied all the files off it onto a Windows PC. I left this running overnight.
All worked well.
Tonight I have deleted the partition on the original XFS NAS disk, and created a new ext4 one.
I've mounted it, modified fstab to mount them both, and modified samba.conf to share out both disks.
Restarted samba and....
I can no longer access either disk from a Windows pc!
The shares both appear, but when I try to access them, I get an error that states "the network path was not found"
If I stop samba, the network shares disappear, as expected. They reappear if I restart samba. But I can't look at files on the shares, I get the "the network path was not found" error.
Any thoughts as to what I've done?
I can understand the new disk having problems (eg permissions) but why has the original disk, which was working ok the other day, stopped working?
There is also a share of the user home folder, and this gives the same error when I try to access it. It is located on the SD card.
I'm assuming it's a permissions thing (?) but what global permissions should I be looking at? How might I have broken it?
Is very frustrating when it was all working well yesterday!
Any thoughts?
Ian
Modified to add : I can access both disks successfully via ssh login on the pi.
-
...
just had brainwave
...
think I've been stupid
-
Yep, my own stupidity.
I'd modified the path to the share to reflect the different directory structures on the XFS disk, and hadn't put it back again to how I'd arranged my new ext4 disks.
So I was trying to share out /mnt/vol1/public and /mnt/vol2/public when it should have been /mnt/vol1/share
Kitz et al : feel free to delete this thread :-[
Ian
-
I wouldn't dream of deleting it. We always enjoy someone suffering embarrassment. ;D
-
Over 2 hours I was cursing Linux and wishing it was running Windows!
I chmod 777'd anything related to samba whilst trying to fix it >:( Got to go back now and undo my clumsiness
Ian
-
As I previously mentioned, elsewhere, I use Red Hat Enterprise Linux and not Debian so I am unsure if there is something in the package manipulation "armoury" that you could use to "undo your clumsiness".
With RHEL it would be as simple as --
rpm --setperms package_name
Where package_name is samba, samba-common, etc.
Perhaps Eric will be able to advise if there is a Debian equivalent to the above rpm command?
-
rpm?
I assume that's setting default/recommended/other permissions for running the named service?
If so, that's a handy utility!
Sadly, in Raspbian (variant of Debian) on my Raspberry pi :
pi@oldpi ~ $ rpm
-bash: rpm: command not found
Once I've read up on permissions a bit more, I'll go back in and set it appropriately by hand, I guess.
Ian
-
Sorry for not being explicit. :-[
rpm (Red Hat Package Manager) is to RHEL (and Fedora and other Red Hat clones) as apt is to Debian.
-
Ah, I see.
I read that with a Microsoft hat on, as they have released a number of "lock down" tools that secure various popular packages (eg IIS)
Ian
-
I know it's all compatibility and stuff, and I was an idiot for getting the settings wrong, but :
If I tried to share out a non-existent directory/folder under samba, should't samba give me an error or warning when I start it?
Rather than me getting errors from Windows that the path isn't available when I clicked on an advertised path?
Anyway, it's working now so grumble
Ian
-
I know it's all compatibility and stuff, and I was an idiot for getting the settings wrong, but :
If I tried to share out a non-existent directory/folder under samba, should't samba give me an error or warning when I start it?
Perhaps it did? Have you checked in the /var/log/messages file? :-\
-
Perhaps Eric will be able to advise if there is a Debian equivalent to the above rpm command?
Unfortunately not (as far as I'm aware). There's dpkg-reconfigure which reconfigures a package, but it doesn't seem to include setting the permissions.
-
Well, today's fun is that I can't get all the files I copied off the disk back onto it again, it's full :o
By totalling up the size of the files that didn't copy back over, I reckon I've lost 15Gb somewhere!
I copied everything off the original XFS disk onto an identically sized NTFS disk over the network.
I removed the partitions from the XFS disk (in fact there was a swap partition and a few other bits, so I imagined I'd gain space!)
I created a single partition, which I believed filled the disk, and formatted it ext4.
I left the files copying back overnight, and this morning found 15Gb of them won't copy as the ext4 disk is already full.
Any idea?
I'm trying to understand this output - have I somehow created a partition that doesn't fill the entire disk? The disk that won't accept all it's files back is /dev/sda :
sudo fdisk -l
Disk /dev/mmcblk0: 16.0 GB, 16012804096 bytes
4 heads, 16 sectors/track, 488672 cylinders, total 31275008 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bf57a
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 2833984 1412896+ e W95 FAT16 (LBA)
/dev/mmcblk0p2 2834432 31209471 14187520 85 Linux extended
/dev/mmcblk0p3 31209472 31275007 32768 83 Linux
/dev/mmcblk0p5 2842624 2965503 61440 c W95 FAT32 (LBA)
/dev/mmcblk0p6 2973696 31209471 14117888 83 Linux
Disk /dev/sda: 250.1 GB, 250059350016 bytes
81 heads, 63 sectors/track, 95707 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4ad5da59
Device Boot Start End Blocks Id System
/dev/sda1 2048 488397167 244197560 83 Linux
Disk /dev/sdb: 160.0 GB, 160041885696 bytes
81 heads, 63 sectors/track, 61254 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2a7ed278
Device Boot Start End Blocks Id System
/dev/sdb1 2048 312581807 156289880 83 Linux
I've not created any other files on /dev/sda, just trying to copy back all the files that I originally took off.
Any thoughts?
Ian ???
-
At a guess I would say that sda1 probably isn't mounted. You've presumably created a mount point for it, but if it isn't actually mounted then you're copying the files to the mount point, not to sda1. If you type "mount" you'll see a list of all the mounted partitions.
-
That would be a nice simple solution, but sadly it seems I have mounted sda1 :
/dev/root on / type ext4 (rw,noatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=85876k,nr_inodes=21469,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=18832k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=37640k)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
/dev/mmcblk0p5 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
/dev/sda1 on /mnt/vol2 type ext4 (rw,nosuid,nodev,noexec,relatime,data=ordered)
/dev/sdb1 on /mnt/vol1 type ext4 (rw,nosuid,nodev,noexec,relatime,data=ordered)
This is what df has to say :
pi@oldpi ~ $ df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 14G 2.4G 11G 19% /
/dev/root 14G 2.4G 11G 19% /
devtmpfs 84M 0 84M 0% /dev
tmpfs 19M 1.4M 18M 8% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 37M 0 37M 0% /run/shm
/dev/mmcblk0p5 60M 19M 41M 32% /boot
/dev/sda1 230G 218G 192M 100% /mnt/vol2
/dev/sdb1 147G 9.5G 130G 7% /mnt/vol1
The biggest disk there is sda1 and it's full.
I know there can be different overheads with different disk formats, eg NTFS tends to use up more space than FAT32... I wonder if there's a similar issue with XFS vs ext4? Seems a lot of missing space though. And I was able to copy the full XFS disk onto a same size disk formatted with NTFS without running out of space, so why can't I get all the data to copy back again? ???
Because I'm really not familiar with Linux and managing partitions, I'm going to put the disk on a Windows machine and look at it with the disk management tool there. Although it won't access ext4, it'll see the partition, and might reveal if there's some slack space if I inexpertly partitioned it.
Ian
-
Anything in lost+found ? ie, /mnt/vol2/lost+found ?
Linux puts broken or orphaned files/blocks there, as may occur when the system crashes or is untidily switched off.
Just a thought. :)
-
I might have found out what's been going on, and for a change it's not me doing anything daft (apart from my choice of disk format.. read on).
The disk had no slack space, the partition filled the disk.
I did a file count on the source disk and the (full) destination, there weren't any duplicate or rogue files, just fewer files on the destination as it had filled up before the copy had completed.
The NTFS disk I was copying from, and the ext4 disk I was copying to, were not only exactly the same size, they were the same model of Seagate disk.
Remember :
"disk1" (XFS) => "disk2" (NTFS) => "disk1" (now ext4)
disk1 to disk2 copy worked without problems, and I had about 500Mb free on the NTFS destination afterwards.
disk2 to disk1 copy then failed as the destination became full before the copy had completed.
I repartitioned disk1, and reformatted it ext4 once more. Looking at the free block count, I noticed it was lower than the free blocks I'd noted when the disk was previously formatted with xfs. Suspicious, I then reformatted with xfs (once I'd worked out how to add xfs tools support to a raspberry pi).
And lo! I now have more free blocks. Many more than when it was ext4, and a few more than it's original xfs format, no doubt due to it also having other (small) partitions then as well.
The proof of it all will be if the copy I'm now doing completes ok, I probably won't know until the morning.
Assuming it works, it would seem that ext4 is less efficient at it's disk usage than xfs or NTFS.
I have subsequently read that xfs is often chosen for NAS servers where you have relatively few files of fairly large size, which is my case here.
Ian :graduate:
-
Quick update on this thread as well,
The problem of copying back the files to the disk from whence they came (and this disk surprisingly filling up before they'd all copied back) WAS down to difference in disk usage / efficiency between EXT4 and XFS.
Having reformatted the disk with XFS, I was able to copy all the files back with no problem.
Format Total Capacity (df)
Original NAS XFS (also had swap partition) 243819836
Repartition, format EXT4 240233144
Repartition, format XFS 244078324
The partitions were identical in size, using 100% of the disk, except in the first instance where there was also a swap partition present from the NAS.
Interesting to note the overhead of EXT4!
Note also that the same capacity hard disk, formatted with NTFS via Windows, was used to copy the data TO and FROM during this exercise, thus NTFS also appears more efficient for storage than EXT4 :-X
Ian