Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sheddyian]

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.

[sheddyian]

...

just had brainwave

...

think I've been stupid

[sheddyian]

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

[roseway]

I wouldn't dream of deleting it. We always enjoy someone suffering embarrassment.

[sheddyian]

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

[burakkucat]

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?

[sheddyian]

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 :

Code: [Select]

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

[burakkucat]

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.

[sheddyian]

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

[sheddyian]

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

[burakkucat]

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? 

[roseway]

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.

[sheddyian]

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 

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 :

Code: [Select]

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 

[roseway]

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.

[sheddyian]

That would be a nice simple solution, but sadly it seems I have mounted sda1 :

Code: [Select]

/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 :

Code: [Select]

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