Start | Settings | Control Panel | Users And Passwords
Start | Settings | Control Panel | Users And Passwords | Advanced | Advanced User Management | Users
Having access means being able to login as that user, and not get one of these dialogs when you try to browse over to the network disk:
To prevent that, make sure your disk server has that user configured with a correct password, or open the share permissions until you can login as the user, and access the server without getting that error.
If you're disk server supplies its disks via Samba, verify
your Samba configuration is 'open enough' that normal users and the Rushd
service user can interact.
# Disk entry excerpt from smb.conf [jobs] comment = Jobs Disk path = /raid/jobs read only = no public = yes <-- public access guest ok = yes <-- guest access force create mode = 0666 force directory mode = 0777 hide dot files = no
This will open up permissions to your disk such that, for sure, you won't get the above dialog after you login and access the server.
Then tighten down security from there, making sure you don't re-induce the dialog. Make sure you have your Windows machines set up to correctly work with Samba to manage password logins correctly.
Here's an actual production smb.conf file used on a Mac OSX (Tiger) file server for a farm of PCs. Your mileage may vary -- for reference only:
[global] workgroup = MYSTUDIO server string = Tahoe # Added to support browsing -- See BROWSING.txt browseable = yes domain master = yes local master = yes preferred master = yes # Logging.. os level = 65 log file = /var/log/samba/log.%m max log size = 50 # Very open security guest account = render security = share encrypt passwords = yes # Remove limit on # of connections # (If unset, default is 10!) # max connections = 0 # DISABLE OPLOCKS TO ALLOW UNIX AND NT TO ALTER SERVER DATA # If no: clients won't cache, but will stay in sync # If yes: clients cache, but out of sync with unix # oplocks = no # Misc preferences socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 dns proxy = no [jobs] comment = Jobs on Tomas path = /Volumes/Raid5 read only = no public = yes guest ok = yes force create mode = 0666 force directory mode = 0777 hide dot files = no
To fix this under Windows 2000:
Start | Control Panel | System | Advanced | Environment Variables
There should be NO SPACES, and there should be a ';' at the end of what you typed, so that it separates your entry from the settings that follow it.
Since you set the name of the user the Rushd service runs as, you have to make sure these directories have permissions that allow access to this user.
You can either use the Window's GUI interface to modify the permissions, or you can use the DOS 'cacls' command. Here's some quick cacls examples:
USING CALCS TO VIEW EXISTING PERMISSIONS ---------------------------------------- calcs c:\rush\var -- view the permissions on the c:\rush\var directory calcs c:\rush\var\* -- view the permissions on the files in c:\rush\var USING CALCS TO ENABLE ACCESS TO THE RUSHD SERVICE ------------------------------------------------- net stop rushd -- stop the daemon first cacls c:\rush\var /E /C /G everyone:F -- full r/w access on c:\rush\var directory cacls c:\rush\var\* /E /C /G everyone:F -- full r/w access for all files in c:/rush/var cacls c:\rush\etc /E /C /G DOMAIN\user:F -- service r/w access to c:\rush\etc directory cacls c:\rush\etc\* /E /C /G DOMAIN\user:F -- service r/w access for all files in c:\rush\etc net start rushd
Replace "DOMAIN\user" with the username you have configured for the "Log On" tab the Rushd service is running as, eg. XYZSTUDIOS\render for a Domain 'render' user, or eg. .\render for a local render user.
See 'cacls /?' for more info.
runas /user:.\render cmd
This will open a new DOS window that will be running as the user the Rushd service, and commands run in that window should have similar access permission.
echo foo > \\server\somedir\foo.txt
If you get 'Access is denied' or "File Not Found", then you can debug it from there as an account configuration problem.
If your network is using "Windows Domains", make sure the Rushd service is running as the DOMAIN user, not a local user. For instance if your Windows Domain is "MYSTUDIO", and the domain user you want Rushd to run as is "render", then the Rushd service's "Log On" tab should show:
In either case, make sure the user's password is configured to never expire.
If your file server is a unix Samba server, verify Samba is configured to be open enough to allow read/write access to all users that own the files.
Note that both "Professional" and "Server" versions of Microsoft Windows both "come with" a Microsoft telnet server that you can enable.
C:\> telnet localhost Welcome to Microsoft Telnet Service login: .\render <-- get this from the "This Account:" field above password: ******** C:\> dir \\some\path\youre\having\trouble\with\
If you're having write permission issues, try also seeing if you can write to the directory using 'echo', eg:
echo foo > \\some\path\youre\having\trouble\with\foo.txtIf you get permission errors, then you've replicated the problem, and should at least be able to troubleshoot interactively (instead of through rush) as you make administrative tweaks to your file server.