Posts Tagged Samba
If you want your Raspberry Pi to share its files and folders over the network, you want to install and configure Samba.
Start off by installing the basic Samba requirements:
sudo apt-get install samba samba-common-bin
Edit the samba config file
sudo nano /etc/samba/smb.conf
edit the workgroup= line to match your network. workgroup=WORKGROUP is the default and usually fine. It needs to match what your Windows PCs are set to.
[pi] path=/home/pi browseable=Yes writeable=Yes only guest=no create mask=0777 directory mask=0777 public=no
Add the pi user to samba. Use the same password for the pi user:
sudo smbpasswd -a pi
It takes about 2 minutes for the changes to take effect, but after this you should have no problem exploring files over the network. Note that some may be owned by root and you may have an issue writing to them.
If you have trouble logging in under Windows (password errors), try using “raspberrypi\pi” (raspberrypi-backslash-pi) as your username (without the quotes)
Previously using Ubuntu, I never ran into this issue, but using openSUSE I couldn’t get logged into a Samba share using any user accounts. Turns out, the users have to be added to Samba seperately. Ubuntu probably did this through the adduser (useradd?) script. In openSUSE, you have to add the user manually.
You can either use pdbedit, or smbpasswd. Both work.
I won’t give examples here, as using –help for either program will spit out very useful and non-confusing examples. But, that’s how.
openSUSE Dolphin brower gives error “Unable to find any workgroups in your local network. This might be cause by an enabled firewall.”
To solve this:
Open up YaST > Network Services > Samba Server. Go to the “Identity” tab, and make sure the Workgroup is set correctly, and set Domain Controller to “Not a DC.”
I’m mostly documenting this as a way for me to remember it, but anyone is free to learn from my doings or leave their own comments.
Configuration is 3x2TB hard drives in bays 0, 1, 2. Bay 3 is empty. (I’m considering adding a 4th 2TB drive and reshaping to RAID-6 at some point in the future.)
Partitioned as follows (MBR):
- 50GB as RAID
- 4GB as RAID
- 1.9TB (max) as RAID
RAID setup (mdadm) as follows:
- md0: partition 1 (50GB) RAID-5, 3 units, 0 spares. EXT4, bootable, mounted at / [Total 100GB+parity]
- md1: partition 2 (4GB) RAID-5, 3 units, 0 spares. swap [Total 8GB+parity]
- md2: partition 3 (1.9TB) RAID-5, 3 units, 0 spares. EXT4, mounted at /srv [Total 3.8TB+parity]
Packages installed during installation:
GRUB installed to MBR
The very first thing to do after installation is to update. SSH in and run the following:
sudo apt-get update sudo apt-get upgrade
May get the following complaint about kernel updates being held back:
The following packages have been kept back: linux-headers-generic-lts-quantal linux-image-generic-lts-quantal 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
This is the fix:
sudo apt-get dist-upgrade
Coming up… more installations…
The following error appears if you try to include a system image in your backup using the Windows 7 File Recovery backup tool.
There was a failure in preparing the backup image of one of the volumes in the backup set.
Details: The mounted backup volume is inaccessible. Please retry the operation.
Error code: 0x807800C5
According to this forum…
For Win 8 only: The Win 7 back up program included with win 8 does not support backing up a image file to any kind of NAS device (UNIX, Linux) . Internally the program gives an error that the NAS device has an incompatible sector mapping type. You can backup to a hard drive that is attached to a different windows machine and then back up that file to your NAS. Convoluted, but it works.
So, backing up a system image to a Samba share is out of the question. To work around this, disable the creation of a system image in your backup.
I haven’t tried backing up to an NTFS-formatted iSCSI LUN, which might work. If anyone has tried that, I’d be interested to know the results.
If you use Windows 7 File Recovery to attempt to backup your system to a NAS device, you may receive the following error:
0x80070544: The specified network location cannot be used.
Verify the path points to a correct network location and that the supplied credentials can be used for write access to the folder.
The validation information class requested was invalid. (0x80070544).
The solution to this is rather simple. You have to prefix your username with the name of the machine where the Samba share is located. So, if you are backing up to diskstationbackups, prefix your username with diskstation.
In my case, my username on that device is mike. So instead of using mike as my username, I had to use diskstation\mike.
It works now. Enough said.
In OS X Snow Leopard, you may experience problems accessing a SMB network share using either of the following methods:
Go > Network;
or, using Finder’s pane, under Shared;
.. and clicking ‘Connect As’ to log in.
You get the following error message:
You entered an invalid username or password. Please try again.
In Safari, type the following into the address bar:
Where servername is the server name of your SMB server.
a dialog box will appear, prompting you to log in. This should succeed and you will be prompted with a list of your devices shares. Selecting a share will mount it and display the contents.
For about a week now I’ve been wrestling with implementing a system where CrashPlan would backup to my network drive. I ran into a really bit problem: When you mount a network location in Gnome using the GUI (gvfs), root can’t access it. Since the CrashPlan engine runs at root, it makes the network location unusable as a backup destination.
After a while of working on different ways to solve this rather large hurdle, I came up with the idea of simply mounting the network location using smbmount (mount.cifs). After some testing and tweaking, I was able to get it successfully working and added an entry to fstab to have it mount at boot time. I chose /mnt/mynas as the mount point.
See Synology DiskStation and Samba mount permissions for my method of getting it mounted with the correct file permissions.
Once it was set to mount at boot-time, I can now open the CrashPlan client and set /mnt/mynas as a destination folder, and now I have both local and off-site backups!
Feel free to share your thoughts and/or feedback in the comments below!
So today I was using smbmount to mount a network share from my Synology DiskStation to my Linux PC when I noticed a rather annoying file permissions issue that I couldn’t seem to fix. Why am I using smbmount and not Gnome’s GUI to mount? Because I need root to have access to the file system as well so that CrashPlan can back up to it.
Here’s what happened:
First, I mounted the share (as root):
smbmount //diskstation/mike /mnt/mynas -o credentials=/home/mike/mike.cred,uid=mike,gid=mike
(For more information on the smbmount or the mount.cifs credentials file, see the Ubuntu manpage for mount.cifs)
That worked great, except for when I do this (as root)…
ls -ld /mnt/mynas
… I get the following output:
drwxrwxrwx 17 mike mike 0 2011-05-20 09:25 mynas
I sure didn’t want the directory world-writable. So I tried specifying
dir_mode as both
0755 using the following (as root):
smbmount //diskstation/mike /mnt/mynas -o credentials=/home/mike/mike.cred,uid=mike,gid=mike,file_mode=0755,dir_mode=0755
Then I checked it:
ls -ld /mnt/mynas
… and got:
drwxrwxrwx 17 mike mike 0 2011-05-20 09:25 mynas
That didn’t do anything at all to help. Why? Because as it turns out the DiskStation is using a Samba server with CIFS extensions and is passing the permissions to smbmount (mount.cifs). The
dir_mode options are ignored if the remote server is using CIFS extensions.
If the server does not support the CIFS Unix extensions this overrides the default file mode.
If the server does not support the CIFS Unix extensions this overrides the default mode for directories.
Source: Ubuntu manpages.
So there’s a couple of options here. First, I could set it to mount somewhere inside /home/mike, which would generally protect it. But I’d really like to know what’s up with the file permissions. So I did a little more Google-fu.
As it turns out, the CIFS extensions on the DiskStation can be disabled, all it takes is to edit a file. Lepoulpe posted on the Synology forums the following edit:
you can disable “unix extensions” in the ds106’s samba server. To achieve this, you need to add the folowing line in the [global] section of /usr/syno/etc/smb.conf :
So, I SSH’d into my DiskStation as root (should be the same password as ‘admin’ if you’re having trouble) and used the vi editor to make the edit. Afterwards, I restarted samba on the DiskStation by doing this:
Then I remounted the Samba share as root…
smbmount //diskstation/mike /mnt/mynas -o credentials=/home/mike/mike.cred,uid=mike,gid=mike,file_mode=0750,dir_mode=0750
… and checked the permissions:
ls -ld /mnt/mynas
… and got the following output:
drwxr-x--- 17 mike mike 0 2011-05-20 09:25 mynas
So now I have /mnt/mynas mounted to my share on the DiskStation. If I wanted it to mount on boot, I could add something like the following to /etc/fstab:
//diskstation/mike /mnt/mynas smbfs auto,credentials=/home/mike/mike.cred,uid=mike,gid=mike,dir_mode=0750,file_mode=0750,user 0 0
Questions about my method? Have any feedback or alternate methods to share? Please feel free to do so in the comments below. Thank you!